The core Windows APIs don't have any problem with accessing the file stream "foo:bar". It is just some applications which apply their own file name validation and reject it before passing it to the underlying APIs.
That is seen even in some programs shipped with Windows. For example, cmd.exe. Some of the built-in commands in cmd.exe, for example "del", "type" and "copy", refuse to work with file streams. But that's because cmd.exe's code is detecting the colon and rejecting it as bad filename syntax. If Microsoft would just comment that validation code out, and pass the name including the colon down to the core Windows APIs, those commands would work. But that said, other parts of the cmd.exe code can handle them. The "dir" built-in command even has an option to display file streams, "dir /r". You can also read/write streams using redirection in cmd.exe, e.g. "echo foo > bar:baz" will write the string "foo" to the file stream "bar:baz". And "more < bar:baz" can be used as a workaround for the fact that "type bar:baz" doesn't work. Even though "copy" doesn't understand streams, "copy foo bar" will copy "foo" with its streams intact (assuming both target and destination are on filesystems that support streams), since even though "copy" doesn't understand streams the underlying Windows file copy API it calls does.
Microsoft is unlikely to fix the limitations in cmd.exe since cmd.exe is now considered a legacy component. New features all go in PowerShell. And PowerShell has much better support for streams, it can do everything with them.
So the "generally not" really depends on which applications you are using.
That is seen even in some programs shipped with Windows. For example, cmd.exe. Some of the built-in commands in cmd.exe, for example "del", "type" and "copy", refuse to work with file streams. But that's because cmd.exe's code is detecting the colon and rejecting it as bad filename syntax. If Microsoft would just comment that validation code out, and pass the name including the colon down to the core Windows APIs, those commands would work. But that said, other parts of the cmd.exe code can handle them. The "dir" built-in command even has an option to display file streams, "dir /r". You can also read/write streams using redirection in cmd.exe, e.g. "echo foo > bar:baz" will write the string "foo" to the file stream "bar:baz". And "more < bar:baz" can be used as a workaround for the fact that "type bar:baz" doesn't work. Even though "copy" doesn't understand streams, "copy foo bar" will copy "foo" with its streams intact (assuming both target and destination are on filesystems that support streams), since even though "copy" doesn't understand streams the underlying Windows file copy API it calls does.
Microsoft is unlikely to fix the limitations in cmd.exe since cmd.exe is now considered a legacy component. New features all go in PowerShell. And PowerShell has much better support for streams, it can do everything with them.
So the "generally not" really depends on which applications you are using.