I think, that your wish will not come true. I hope for it, because having only one place for all Arduino libriaries, with no libraries allowed not be there and all those libraries would be forced to stand all commercial standards of quality, testing and documentation (+code quality, effectivity and readability) would mean, that only professionals and similary qualified teams would be allowed to publish some Arduino library and it all would be governed by one single entity, which would enforce removing functionally duplicate or similar libraries. And such entity would soner or later became evil.
I like the Arduino for being free and that also means, that I am free to write library for support of some features (which I want to use) of some hardware (which I have, plan to buy or want to make myself - even highly experimental and maybe unstable, but fun for me).
With your Big Central Authority being effective, I would just choose another free platform, rather then be sued for lesser than perfect and commercially certified outcome of my hobby playing with electronics and forced to work for their, NOT my goals on MY free time.
And if your Big Central Athority would not force me to forced free labor work for them, then what would you do about my library enabling one special use of some common hardware, and about me sharing it to anyone want it, even if it does not solve all the HW functionality fully in proffesional matter and documented only so much as I would be comfortabe to spend my own free time with documentation. And what if there would arise another library for the same HW, which would enable another part of functionality or would use another API and another approach to the whole problematic?
Namely I bought some multi 7-segment module and there was "official library" for it from its manufacturer. I made another library for the same module. What now? Should be my library be in the Central Repository as "the only one library for this HW" or should be there the "official one from manufacturer"?
Note, that if there were both of them, than it would break your requested "one and only one" library point.
If you disallow the manufacturer one, then "the only one" would be missing a lot of features, as integrated buffer for numbers, simple object interface, simple example, how to use it and there would be hard dependency on one specific timer and generic non-object, just functional API, which would require user to break integers to single digits somehow - does not sound too good.
If you disallow my library, then user would have the above, but his display would refresh only 10x per second with blinking and leaving ghosts of other digits all over place, while fully utilise processor and the documentation would be mainly in chinese. And the user would miss refresh rate 100x per second with nearly no usage of processor, nice clean digits AND characters (potetially also user defined). - Also not good.
In current state of chaos user (maybe you or anyone else) can use the library, that is better fit for his needs (be it simplicity and native integer support, or be it clean fast refresh and low CPU usage) or combine both together, making third with fast refresh AND simple integer manipulation AND user defined charset, WITH nice object API and rich documentation. It only needs one person with some time and dedication make it easy for beginers and some english skills and basic knowledge of objects and how are "official Arduino libraries" packed, so the IDE can easily import them. (And such person should do it and contribute it to Arduino library packager).
I would not do it - for my needs is functional API far better and simpler to use, take less bytes from memory and less CPU cycles and I have no urge to improve the library in ways I would not use. Also I do not use Arduino IDE, I use simple Makefile to build and upload the programs, so I can easily use good text editor (vim in my case) and have not to fight with IDE-Notepad-parody.
Under Big Central Authority enforsing your model I would not care about using Arduino at all and you will be stuck with the chinese version, if any at all (as it would not make it there for lack of good english documentation and proper package format too).