(1) Currently, ProjectExporter::createPlatformDefaultExporter tries to find the best ‘exporter’ for a particular platform. However, since “bestPref” is set to 0, it’s entirely possible for it to search through the list and find no ‘better’ exporter.
(2) When a project is saved, this will cause ModuleList::getDefaultModulesFolder to fall back on ~/juce/modules. There does not seem to be an error if that platform doesn’t exist, so the Introjucer will simply not load any modules.
(Result) If you have an Android project, which requires the core module, this will cause the error “To build an Android app, the juce_core module must be included in your project!”
I’m not sure if the intention of #1 is for a preference of 0 to indicate that the project can’t be built on the current platform. If it is, not finding an exporter should probably be an error (“No project files will be built that can be used on this platform”). If the intention is for the best project to be used (even if it can’t be built on the platform), the resolution is to set “bestPref” to 0.
#2 should probably result in an error regardless (“Unable to find Juce modules folder at …”), and/or additional error-checking should be added to go off if a project specifies a module that Introjucer can’t find (“The following modules were specified, but could not be found at …”).
EDIT: This will only happen on a project that doesn’t have the ‘default’ exporter for that platform (eg Visual Studio on Windows).