Parts Editor can only ‘edit’ the fzp file content. It has no ability to make changes to any of the svg files. All it can do is import a new image that has been created or changed using some other tool.
Modifying fzp files directly in the Fritzing user folder is a bit of a ‘risk’, in that it is quite possible to break a part definition with an incautious change, that Fritzing might not notice (until much later), because it did not see it during the import process. I do not know how much actually gets looked at during the import. It might be just what the svg files are, and that they match the defined view paths. The only ‘requirement’ for the import, is to unzip the fzpz file, put the contained fzp and svg files in the correct folders, and check if the module ID is already being used by an existing part. It might do more, which would be bypassed by direct edits.
Due to that (lack of knowledge), I prefer to always do editing outside of the Frizing parts.user, parts.svg folders, and let Fritzing do the import of any changes. Though that means that the existing part has to be deleted from the bin first, to prevent conflicts with Module Id (unless that is changed as part of the edit). If you are doing the changes with Parts Editor, that does not apply. It will be doing the work directly on the files in the parts sub-folders, but it can also do whatever validation is appropriate.
I Agree that there is no single ‘best’ process. For ‘my’ process, I have a folder I use for checking (not usually changing, except as part of a test) parts. That has a notes file with information I find useful during testing. That includes content templates to use for reporting results when checking one of the parts submitted here. That folder contains 2 subfolders, one I use to run FritzingCheckPart, the other to inspect the raw fzp and svg files for a part.
For working on a part, I create a new folder. If the starting point for the new part is an existing core part, I create a copy of the part in Fritzing, export it, then unpack the fzpz into the working folder. I do not save the copy of the part in the “Mine” bin. If the base is an existing custom (user) part, I start from the fzpz for that (or recreate it as an export from the bin). Otherwise, I take sample and template files from various places, depending what the new part needs, and what I have (and can find). Initial export, and later import, is the only thing I normally use Parts Editor for.
After creating an initial version of the part files, I zip them into a fzpz, switch to the testing folder, unzip, and run FritzingCheckPart. Repeat until get a mostly clean report (and all remaining warnings explained), then import into Fritzing for visual checks and testing.
Repeat some more, Possibly first deleting a conflicting part. Usually there are no conflicts, because I do not save the ‘test’ version of parts in the Mine bin, and one of the initial changes is to set a new module id in the part. Sometimes a Fritzing (or computer) crash leaves pieces behind that need to be cleaned up manually.
With this, there should not be any need to run the “regenerate parts database” command. The import should do everything that is needed. Editing fzp or svg files directly in the parts sub folders “might” needed a regenerate. I do not know everything that it checks and builds indexes for. That command is intended, as far as I can tell, to rebuild the cached information after the core parts library has been updated. So after a the Fritzing has downloaded core part updates from the github repository.
The above is for working with “custom” parts. The process is different for making changes that are intended to be incorporated into the core parts repository. For that, I have a separate copy of the parts repository, or at least a separate branch, in a fork of the repository. Files are edited ‘in place’ in that branch, and testing is done by pointing Fritzing to that parts library. Changing to a different parts library is another reason to use the regenerate command. The other differences for changing the core parts library are mostly around the requirements of the git process of tracking changes. I still use a separate folder to run FritzingCheckPart against a copy of the new and changed files, but that is a bit more involved. It needs to duplicate the folder structure used for the core parts, but only contain the files to be checked, each in the correct folder. I normally write a small (bash) script to copy the files to where they are needed for testing. The script is created for each set of parts being worked on as a group. I had a single main folder and script when I was working on the 8 by 8 led matrix parts, though that was for 16 parts. The parts shared a lot of the same svg files in different views, in different combinations. It was really 4 different sizes, each with 2 different polarities, each with 2 possible pcb footprints.
That outlines the basic process, with minimal details about what is involved in the editing and testing.
A separate “install” of Fritzing can help in the various scenarios. But ONLY if you can manage the files that are expected (by Fritzing) to be in known locations. There is a command line flag that can be used to point at a different parts library folder, but the user configuration and user parts folders are still going to be shared. Unless that alternate install is also for a different user, or on a different computer. A different computer could also be a virtual machine. A different computer (or VM) is safest. There should be no interaction with the other install that way. I ‘accept’ the common files, an just specify a different part library when needed for basic part editing. I use a VM to be able to test using the Fritzing 0.9.5 development version.