There are fully specified symbols. Such a symbol is typically named after the part number it is valid for and has the correct footprint already assigned in the library. It is the responsibility of users to then add their order information as the official library team can not show bias towards any distributor and it can not maintain order information for every distributor out there.
One of the strong points of KiCad is that you can assign a symbol to any footprint. This is only possible because the libs are separate! Most components come in standardized (JEDEC) packages. It makes sense to have a library of footprints generated using an industry standard (IPC) for them.
To manage such a library efficiently you need to have the option to organize symbols independent of footprints.
- For symbols organization with regards to function makes sense. Symbols after all are there to abstract the function of a part. (For example a lib for all voltage regulators)
- For footprints however organization against general shape attributes (example lead style, lead placement, …) makes more sense. (for example a lib for qfn packages)
I currently work with eagle and see how badly its system deals with this. I either need to duplicate the footprint of the same package in multiple libraries (maintenance nightmare) or need to have symbols organized per package (which breaks some important eagle features so yea maintenance nightmare it is) This simply does not scale to the size of the official lib let alone to the size of the library a distributor would provide.
I made the assumption that you mean management in the sense of making a good organization instead of management in the sense of having it easy to download and use assets. The downloading and “installing” of assets is indeed easier in tools that have a combined file format as one needs to only add a single lib in that case. But i think this is a trade-off worth taking.
And it is not even that hard to import assets into the existing organization:
Snap eda can provide a KiCad library. This is their decision. (digikey for example started one.) But we will never let a company run the official lib.
KiCad could provide a standardized API for enabling such a usecase but i do not think this should be configured out of the box to provide an interface to a single distributor.
I point you to octoparts recent reversal of API licensing for an example why it is a bad idea to lock a tool to a specific external entity.
All KiCad assets are contributed by the community. We have two options. Accept that people are more likely to provide footprints and have a large library of them at the cost of not having 3d models for everything or require every footprint contribution to also come with a 3d model which would drastically decrease the number of contributions we get.
But yes currently 3d models are assigned using the file system path which makes it quite inflexible. I think version 6 will bring a library based system for 3d models.
So you are aware that the same footprint can be shared by a huge number of symbols. Interesting. Were you just unaware of the fully specified option? (What you say here in part contradicts what you request above)
Also yes right now a different pinout would require a different symbol. It would be nice if symbol aliases could define a different pinout. I think this will become possible with the new file format via the inheritance feature (note: I speak of the file format. We have no idea how this will be abstracted in the user interface as the file format is not yet implemented. We are also uncertain which parts of the file format will be implemented in the first iteration.)
Sorry that we do not have every component in existence represented in the lib. Especially sorry that we do not have obscure parts in the lib. Yours truly the head of the kicad library.