cmaglie:
EDIT: Hopefully, Maker A and B would send their patch to Maker C (the original library author/maintainer), to include it upstream, instead of making their fork.In this case the work needed by C is to accept the pull request coming from A and B and, eventually, solve the conflict on the "architectures" line of the library.properties.
History has shown "Maker C" often abandons their library after about 6 months to a year, after they've completed whatever project motivated writing the code. Even today, there are still many minor Arduino libraries that have "#include <WProgram.h>" for pre-1.0 Arduino.
Libraries published by companies that support a shield, breakout board or other hardware they sell are an exception, but even with those, not long after initial release there's little incentive for those 3rd parties to merge patches or pull requests from Maker A & B. They generally will merge patches from "Maker A" who is also a commercial operation and has a sizeable installed base of boards on the market, but "Maker B" who is a hobbyist selling few if any boards will generally be ignored.
BTW this is a process that cannot be enforced by the tool.
Well, of course not.
But the tool could support a way for Maker A and B to supplement the library with extra info, in a way that won't clobber each other and any revisions from Maker C.
I'll certainly be in the Maker A or B roll regarding many libraries. If Maker C won't accept my patches, I'll fork or patch the library as needed. I'll try to do so in the best way your infrastructure supports.
I'm really glad you're concerned about this stuff. 1.5.x is already a huge improvement over 1.0.x. But in designing this structure, it's pretty clear from the many years of Arduino's history that depending on library authors to actively maintain their code and merge patches from 3rd parties is not very practical.