I’m glad you asked! I know of one situation where it seems like the KPN is just the easiest way. It just so happens that Digkey has thrown a monkey-wrench into the works. A person can order their Digi-reel. The MPN of the part number is the same, but the order-able part number is not.
Using a KPN, then the OPN (Orderable Part Number), could be the MPN or the Digikey number.
My comment was slightly off-topic since I thought of all the past discussions where people asked for an additional field to be added to the current (non-atomic) libraries to house their HPN/MPN/etc. but could not agree to a common name for that field.
If it were called “KiCad Part Number” there would be no mistake as to what the purpose is: An identifier for the part inside the KiCad libraries.
This was not to say that the KPN field should be pre-populated with a number, it ist just a name for a field. People are then free to use that field for their HPN, MPN, PON or any other numbering scheme they need for their purposes.
Anything that @Sprig wrote after my first comment pretty much says everything else about the use for the KPN inside the atomic libraries.
Why not start with what EAGLE has done, and take advantage of all their thought and experience?
I don’t think Atomic Parts should be separate as they are a superset of the Symbol and Part.
KPN sounds good, but I think there should also be a ‘display key’ field. It’s nice to have a globally compatible idea, but the truth is most users have a set (relatively) few number of ‘favorite’ parts that they go back to again and again across numerous projects. I think those are the best candidates for Atomic Parts – all the project-unique and one-off uses don’t really warrant the time to create an Atomic Part, and keeping track of and using all that madness (in the form of huge KPN’s that are just ‘foreign keys’ that concatenate various other part database fields) seems to be an endless blackhole. Maybe I’m talking about a Favorite Parts as a subset of Atomic Parts…
Also, I’m pretty sure there needs to be built-in the expectation that the datafields are going to grow in number, change names, and be different amongst various supplies, manufacturers, and users. EAGLE allows this, although clumsily, in their “packages”, “attributes” and also “technologies” features that are attached into devices (ICYDK, a device is a part + symbol and the pin-pad interrelations).
Actually there is a very good reason, which is that people have different requirements. Usually that means there are different applications, but often people doing the same task have different requirements depending on the scenario. Anyone who says “there is one solution that fits everyone” probably hasn’t done much work with engineering, or people.
At work we design with an in house part number which specifies a functional part, and we provide a list of manufacturers with second sources if applicable. It’s up to manufacturing/purchasing to decide what packaging they want, and where to buy.
That is just one of many scenarios. Small companies with no specialist buyers, companies who outsource. Probably people working in safety critical would never let purchasing decide on a part, they might even need to sign off parts on a batch basis.
Anyway, nothing I’ve seen here suggests there is anything close to agreement, nor is anyone willing to put in the effort to make it happen. People seem to think if there was a default, approved KiCad field name, all the rest would magically happen.
I am increasingly of the idea that the best way forward for commercial users of KiCad is to partner with information providers who already have the data and a business model to support it. For KiCad users creating Open Source projects, they will have to make do with public sources of data. Arguably as soon as you attach a specific MPN or vendor SKU to a part, you entering non-Open territory anyway.