There are bugs, there are design flaws, and there are limitations. Often people are confused how to classify an issue between these categories.
This is a 44 year old limitation.
This is a 44 year old limitation.
"it's not a bug, it's a feature!"
A correctly working system would have simply said what limitation the user had hit.
I’m sure that in every file system there are names you can’t give a file - and if there aren’t then that problem is at least as big. For example if it’s possible to call files null, the empty string, “.”, the directory separator etc then that just creates more trouble. These are documented limitations and a non-buggy system will explain what limitation the user has hit.
Inconsistency such as differences beteeen file system and file explorer I could agree are borderline bugs at least in the UX sense. The user doesn’t see the file explorer UI and the file system as different things.
It's that failure to appreciate quality as a relationship which is the confusion.
Imagine being a developer of some windows software, and a QA person in your team notices that the software can't save to "aux.foo". You explain that this is a limitation of the Windows OS and you can't fix this. But QA insists that this is a "showstopper", and management agrees.
So you do a bit more research and you discover the work-around with the "\\?\" path prefix. You implement the "fix". Now QA discovers that they can save to "aux.foo", but windows explorer has weird issues with it, and they can't open the file in a text editor, and the file doesn't get backed up anymore, etc.
Wouldn't it have been better to accept the limitation instead of calling it a showstopper?
Unlike Microsoft's case, this one wasn't required for backwards compatibility. It was simply a dumb decision that nobody wanted to revisit.
If that’s not technically a “bug” then it’s still broken UX (and the error message produced certainly doesn’t help there either).
Limitation? Yes.
Design flaw? Hell yes.