@LPChip's answer is the answer that solves your problem, but I have more details that I think warrants another answer here.
Filesystems are data structures that manage your files on a disk, so normally FS themselves have minimal restrictions on file names - most modern FS (NTFS included) can even technically hold null bytes just like how Python holds strings (length + array of bytes).
That FS supports arbitrary strings does not mean you should. Practical operating systems impose restrictions on file names so that they can present a sensible "path" interface to the upper level, where applications can access files.
This is the reason every OS has some limitations on file names. Notably, Linux and other Unix systems allows all characters except the null byte and the path separator (forward slash) in file names, excluding two reserved names . and .. (current directory & parent directory). Windows, for historic reasons, reserves more characters and more special names (e.g. CON, LPT, COM1 to COM9 etc.) through normal Windows API, but still allows these names via a low-level API as used by WSL1. For example, you can create something like /mnt/c/CON in WSL1 and use it normally, but you can't do anything with it outside WSL environment.
On Linux, fsck programs can rewrite invalid file names if they somehow end up in the filesystem. I suppose chkdsk.exe can do something similar but I have not verified that.
