I retrieved tags from Amazon for an album that had a song named something like "first/second.mp3". Since my own filenames for that album weren't right, I executed "rename files from tags". During that process, mp3tag created a subfolder named "first" and inside a file named "second.mp3".
While this is not exactly dangerous, I can't think of a scenario where this would be intended. Also, there may be other special chars coming from external sources containg more undesired chars for file naming. Maybe mp3tag should consider these chars when executing something like renaming from tags.
The / is a valid character in Windows.
If you are not sure whether your filenames will end up with valid characters, use the $validate() function for the whole filename.
If you have more special characters that you want to replace with a special (other) character, uste the $replace() function for that piece of data.
Also see the FAQs on the Convert function and the possibility to create folder structures: /t/8016/1
Good to know that I can handle these cases with special functions during renaming, I didn't know that yet.
Nevertheless, the bug report was merely referring the default behaviour of the renaming process when renaming files from tags that were retrieved from online sources. By default, characters that lead to something else than a single valid filename (no folders etc.) are allowed.
From a safety and usefulness point of view I'd reverse that behaviour to disallow these characters when renaming from tags (replace or exclude them). If someone would not like to have these chars replaced or excluded, then he/she might use a function to keep them.
Imagine renaming a lot of album tracks through freedb or Amazon: you never know what kind of track names might come back. So right now I'd basically have to validate them all.