Just a short comment, I agree that "parse_float" is an unfortunate name, which also confuses me in retrospect. "parse_real" will be more fitting, especially since the source use this term internally. I am not sure it is enough to justify the change though.
Concerning the custom separators, and why the implementation supports them, I believe it is not actually about the separators themselves, but the whitespaces around them. When you generate JSON with an indentation, you probably also want some spacing after double colon or comma so it looks "pretty".
While when creating JSON for "machine" processing, you want it as dense as it gets, without any unnecessary whitespaces.