Great to see the level of interest and discussion on this topic!
I feel though that it strayed a bit more onto the need for pin numbering, and specifically the need for correct pin numbering. This point does not need to be defended… because correct and standardized pin numbering is so very crucial for the thing to work when physically realized.
But then my point was not to weaken that. My intent was to stir up a discussion on what would be good place or asset to conveniently “hold” or “locate” or “specify” pin mapping (e.g. “D” -> 3) while maintaining all those things we hold dear, i.e.
- backward compatibility with existing workflows
- portability (or upgradability) of existing assets (libraries etc)
- ability to work with the appropriate level of abstraction while working with the tool for the task, e.g. dealing with functional unit like say NMOS-FET at the schematic capture, especially at the early stage)
- giving a high level of confidence that the process will yield a working result
- giving a high level of re-use for assets created (symbol and footprint libraries)
A “good place” in the problem statement could be answered in plural, as “good places” which in my mind would accommodate the existing workflow and the way atomic libraries work currently. As a result, symbols could continue to be marked D and 3 simultaneously for those who want that. And yet accommodate other types fo work flows where the mapping is added independently of the symbol – possibly enhancing it (filling in what is missing) or over-riding. I believe the flavour of over-riding is part of the inheritance mechanism in the proposed v6 format (based on my quick read of it).
I may not have explained it well… I will steal a little time here and there and return with hopefully a better write-up of my suggestion.