I think that should be okay :)
I must admit I haven't been following the development of SHA-3 at all, but my understanding is that its genesis (back in the mid-noughties) was that people were paranoid that SHA-2 would be broken by the same sort of techniques that had been successfully used against MD5 and SHA-1. In actual fact I'm not aware of that having happened - if weaknesses in the SHA-2 family have been discovered, I certainly haven't seen any news about them.
So I guess SHA-3 is just an alternative to SHA-2 which, based on present understanding, doesn't really add anything beneficial except being an additional hash function to support. Or have I missed some hidden benefit of Keccak?
(At risk of stating the obvious I'm certainly not suggesting this is a reason for PA not to support the library - this is the totally orthogonal question of why I, as a software author, should use SHA-3 over SHA-512).
I think I'll stick to SHA-2 until SHA-3 has been around a bit longer, if only because its implementation is likely to be better tested in the real world.
@Cartroo: You pretty much have it. Some implementations of SHA3 are faster than SHA2, but you are right that many are looking at SHA3 as having a hash function in reserve in the event that SHA2 does eventually show weakness. Because of the NIST choosing Keccak for being so different from SHA2 it is possible that SHA3 will be broken before SHA2.
Of course let's not forget they chose it because they thought it will stand the test of time. I don't have strong opinions one way or another, but since it is now blessed as the chosen one, there are times I will be using it.
Sure, it looked like SHA-3 could be faster with an optimised implementation. I think I'll stick to SHA-2 for now, give it a year or two for SHA-3 to settle down in the wild and then look again. Heck, I still use SHA-1 in some code today (only to detect accidental as opposed to malicious corruption, though).
At any rate you gotta admit that Keccak is fun to say!!