The file naming applies to the fzp files as well. That is the part file name, and needs to stay unique on disk (within the folder), across all families, versions, variants. So for consistency, it should follow much the same format, so that (for example) tht and smd versions of a part are easy to tell apart. Or variants with different colours, voltages, temperatures, or whatever. The fzp file name needs to be as unique as the property names it contains. Using something like “description_property1_property2_etc.fzp” should work. Where it makes sense, use the same field ordering as for the svg file.
From previous research, Fritzing does not seem to be case sensitive for either the names or values of the properties. I would like more consistency, but different capitalizations are treated the same.
That is my expectation as well.
I do not have the full history, but this seems to be used for a couple of reasons. First, if the family is not changed, then the obsolete part is going to be offered as an alternative in Inspector for ‘swapping’ parts. Second, using a consistent pattern for changing the family name makes it easier to match current and obsolete parts when researching the changes history.
This would only be needed for the obsolete files. The active (core) parts are all “current”. Adding the version number when moving to obsolete should work. It would be a good idea to have git do the rename, so that it (git) better tracks the history.
My research says it is not (ever) a problem. From what I can tell, when Fritzing is started, it reads all of the part fzp files (active, obsolete, and user), and associates the module id with the file (full path). When it opens an fzz file, it uses the module id (not file name) stored in the sketch to determine both what the associated file name is, and where it is currently stored. That handles core, user, and obsolete parts all with one process. The name (or location) of the file is not used in the matching process at all.
The same goes for the view files. The svg file that gets used is whatever is specified in the fzp file that gets used based on the module id. That lookup (seems to have) a search order, but I am not clear on which file will be used if the same svg file name exists in both core and obsolete. Will it use the obsolete one (only) if the fzp is also obsolete? I expect that an obsolete part will use a core svg if the svg is not in obsolete, and (probably) a core fzp will use an obsolete svg, if none exist in core. It is just the obsolete fzp with both obsolete and core svg files that is unclear.
An obsolete part needs to contain a “replacedby” tag, which is what is used to tell the user that the part has been replaced, and which part to offer to replace it with. However many steps (update, save, reload cycles) it takes, that tag with the module id is that chain for updating to new(er) versions of a part. The file names have nothing to do with it. “replaced_by” (also) contains a module id, so again, it does not matter if that points to an active, or different obsolete part.
A side thought. It would be more work, but a user part could be “obsoleted” as well. Maybe. If the fzp in the user folder was modified (still in the standard user folder) to have a replacedby tag, pointing to a different module id, Fritzing might offer to do the replacement, instead of needing to do the delete minus, and reconnect all of the wire. The “maybe” is because I think fritzing stores the whole user part in the sketch file. I do not know if will “see” the replacedby tag when a sketch is loaded.