I agree. I think that something like this could probably fix some things related to song naming (like song_1 issues).
One thing that I’ve realized - as far as I know - is that the Aeros doesn’t seem to save any song metadata alongside the songs themselves. Tempo seems to be strictly determined by the length of the WAV files, and tracks and parts seem to only be only referenced through a naming convention. (This may have changed with the latest update and the new streaming compatibility, though.)
As a developer, my gut feeling is that keeping some type of manifest file (instead of relying upon the filesystem structure) could allow the Aeros to do things like provide an “empty” song without having to save it. (I’d thought about some tricks with file hashing, but an empty track doesn’t necessarily equal an empty file, so that might not work.) I think that an infrastructure change like this - using manifest files for the filesystem and also one per song - could also enable features like locking tracks out of order, temporary unsaved songs, and even “template” files and things like per-song settings. There would likely be drawbacks - exporting songs via storage might not be as simple for the end-user, for instance. But I’m aware that I’m likely oversimplifying a lot here.
These are not feature requests. I’m just brainstorming.