Thanks for the response.
If dontRescanIfAlreadyInList is false, then the plugin will be scanned regardless of if it is up to date or not.
This is not what I see. For me, dontRescanIfAlreadyInList=false does not cause on-the-list/up-to-date plugins to be rescanned (which is explainable to me because the block of code where that bool is evaluated is never entered for on-the-list/up-to-date plugins):
if (file.isNotEmpty() && ! list.isListingUpToDate (file, format))
nameOfPluginBeingScanned = format.getNameOfPluginFromIdentifier (file);
OwnedArray <PluginDescription> typesFound;
// Add this plugin to the end of the dead-man's pedal list in case it crashes...
StringArray crashedPlugins (readDeadMansPedalFile (deadMansPedalFile));
list.scanAndAddFile (file, dontRescanIfAlreadyInList, typesFound, format);
// Managed to load without crashing, so remove it from the dead-man's-pedal..
if (typesFound.size() == 0 && ! list.getBlacklistedFiles().contains (file))
… so if list.isListingUpToDate(file,format) is true, then dontRescanIfAlreadyInList isn’t evaluated because list.scanAndAddFile is never called, nor is nameOfPluginBeingScanned set.
I guess it is debatable the expected behavior of setting nameOfPluginBeingScanned. I may not be a representative enough user, but I’d prefer that value to be set for each true return that scanNextFile() generates (i.e. here’s the plugin that contributed to the call’s return). To me, it is already not expected behavior for a function called scanNextFile() to separately return for each file it evaluates for scanning, whether or not it actually scans it. That is, scanNextFile()==true means either a plugin was scanned and I can trust/use the nameOfPluginBeingScanned value, or it means a plugin was skipped for being already known and up-to-date and I can’t use/trust the nameOfPluginBeingScanned value … but I have to do extra maintenance of previous scanNextFile() returns to decide between those two cases. Like I said, if other users are happy with it as-is, then certainly leave it as-is.