I think it’s been checked against more than the JS one, but I’m not sure to be honest. (@bochaco do you know more there?). You may be right, perhaps the JS version is off and we should patch it. Worth checking for sure. Either way, whichever implementation is broken should be fixed, otherwise it could lead to problems for folk .
There is this only spec I can find.: http://philzimmermann.com/docs/human-oriented-base-32-encoding.txt (I’m not sure what the python impl follows?). What would make it ‘standard’? Surely depends on your favourite standards body no? (Much as there seem to be a few different URL standards), interoperability is key.
If an implementation fails to meet the spec, then there’s an issue there… Same as if an implementation fails with base64 too. Similar consequences I’d imagine. But I’m sorry, I don’t see the possibility of bad implementations as an argument for or against any given spec.
All of which is beside the point, since with CID, you can use your favourite encoding.
If there’s a pressing need for many different encodings to be used via SCL, then perhaps the client lib implementation could allow for passing in your own functionality for the hashing function…?
(Or in general: if the client lib API implementation isn’t something you like, then you’re free to not use it and implement a new API for CID creation, eg. As long as it’s using CID then the urls should be decodable, I believe.)
So far though, I personally still don’t see a compelling reason not to use z-base32 right now though.