Framework developers are a strange bunch. Things outside the ecosystem are generally ignored, and there is a big "not written here" mentality.
So firstly, I would suggest targeting your ideas at the end developer (user of the framework) rather than the maintainers of the projects.
And I think these developers are fairly rational and will look for an existing library before anything else. So the "build it and then they will come" is a pretty sound idea.
If you are looking to organize an agnostic HaxeGameLibs site/repo/group, I think you will get out of it what you are prepared to put into it.
A site with good examples and tests would be a great resource for all haxe developers.
One problem I see with parsers is keeping them platform agnostic as well as efficient. The haxe.format code is certainly platform agnostic, but the typedef/enum structure is generally not that efficient on cpp, and imposes a certain style.
And, say, for a tiled map - do you encode the tileId + rotations/flips into a single "Int" using bit flags, or do you use a class? Maybe a good library would have both options.
Sometimes, it is tempting to blend the implementation with data - for example Svg on a flash-based target using the flash enums for line-caps and blend-modes makes some sense, but no sense in the general case. Some kind of conditional typedef might be a solution here.
Adding a specific renderer(backend) to generic parser also makes the libraries more valuable, although I'm not sure you want to go there. For example, "new spine.nme.Renderer(data)" would be very nice. And perhaps this is just "new spine.Renderer" because "nme" is defined at compile time (and therefore the flash enums are selected too).
I guess this does not help you much. So let me just wish you luck.