Not expecting a limitation like this could lead to undesired behavior (it did!), which would constitute a bug. Maybe 44 years from now, someone will have a nanotech brain implant, and happen to read this tweet and think "AUX.H" and their implant will crash, and they'll have a seizure and fall in front of a bus. Technically, it was a "limitation" passed on, but it turned out there was an associated bug.
The real bug is the misleading "too large for destination" message. The other message "invalid device name" is at least somewhat more descriptive, even better would be "filename is a reserved device name".
This. The file name is explicitly documented as not supported by the file system. The error message is buggy.
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.
This is why I detest talk about "quality" in software. Quality isn't an inherent property - it's a relationship between you and the software. What you might regard as a limitation I might regard as a showstopper.
It's that failure to appreciate quality as a relationship which is the confusion.
Quality is also about other relationships between the software and its environment. It's not just the user and one piece of software in a vacuum.
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?
I remember trying to make that point at a former employer, and getting nowhere. Once something was in the spec it was written in stone, no matter how much pain it caused the users.
Unlike Microsoft's case, this one wasn't required for backwards compatibility. It was simply a dumb decision that nobody wanted to revisit.
Does it even matter? undesired behaviour due to backwards compatibility with a little known (in the wider sense of computer usage) 44 year old feature which brakes someone’s workflow will be interpreted by the user as a bug regardless of whether it is expected behaviour to the developers who wrote the code.
If that’s not technically a “bug” then it’s still broken UX (and the error message produced certainly doesn’t help there either).
This is a 44 year old limitation.