I agree that there are different needs at conflict here; on the one hand the rightful freedom to name layers without having to be subdued to file system restrictions, and on the other hand the need to ensure automation integrity (for those who do need the feature).
As long as PMNG is consistent with its way of handling invaliding characters, exporting shouldn’t be affected then. The problem would be the reverse operation though, for by re-importing exported layers that had their names tweaked to adapt to the file system needs would not be restored with their original names (PMNG won’t be able to reconstruct the original name).
There are some workarounds to this though, e.g. translating invalid characters to their ASCII codes or Unicode code points — which might result in ugly filenames though. If I remember correctly, this is the approach taken by Bash for Windows for handling Unix-invalid characters.
Ultimately, @jan.cosmigo could add a per-project options to enforce/disable strict layers naming conventions, thus allowing both uses.
I think that automation is an important feature for anyone working with pixel art projects on long-term projects, especially if he/she’s working with other team members (e.g. a graphic artist working with programmers). Being able to rely on a scripted toolchain to carry out common tasks dealing with projects manipulations, exporting to other formats, filtering, etc., is an essential part of any coordinated team effort, because it slims down time-wasting operations and allows unattended recurrent jobs to be run over a network.
Of course, ultimately it’s up to @jan.cosmigo to decide in which direction efforts should be invested, and these discussions are a good reference for they represent the various different needs of PM’s user base.
I’ve always considered Pro Motion the state of the art application for professional pixel artists who work in the field of video games; so I’m a strong supporter of all those features that push extending PM (plugins, an API, command line options to run background tasks, etc.), and especially so in the light of how collaborative participation in software projects has drastically changed in the last decade — version control via Git has now become wide spread, and there’s a plethora of third party services for continuous integration and deployment, benchmarking, bug tracking, and whatnot (you name it).
So, it’s inevitable that pixel artists today tend to demand ever more similar features, which allow them to better integrate their workflow with that of their fellow team members who handle programming, sound effects, etc. You’ll notice that today all major applications are investing in that direction, not just code editors, but also graphic and sound editing software, because team work and collaborative editing via Internet services is now becoming standard practice across the whole industry.
But of course, this might not hold true for many PM users, which also include independent artists and developers who are most unlikely uninterested in this type of interfacing.
Hopefully, PM could strike a balance that would not prevent one type of usage over the other. As far as this feature of layer exportation is concerned, it might be a good moment to make a decision that wouldn’t prevent either uses in the future.