System.IO works very well on Linux/Mac right now. It was one of the first things implemented by the Mono team.
Having ported numerous .NET applications, all of which do fair heavily file I/O (the most common use case for System.IO), the main sticking point has been code that deals with filenames and paths. As in "/home/billy" vs "c:\Users\Billy". A hour or so of cleaning up your code and making use of Path.DirectorySeparatorChar and IsRooted is all I've needed to do.
"As it stands the .Net framework/libraries are very Windows locked"
This shows a lack of understanding of the .Net framework. Yes, if you used crazy Microsoft specific WCF libraries for networking protocols instead of industry standard stuff, or used WPF for graphics, that going to be a problem. But there are literally thousands of classes providing a fairly comprehensive set of data structures, network protocols, etc that are completely untied to Windows or Microsoft. If you are using something in System.whatever you are pretty OK.
P.s., Sockets aren't in System.IO, they are in System.Net
Microsoft doesn't need to provide compatibility for the Windows specific bits, as those bits are not part of the Core. And a platform like .NET has enough value in open-sourcing just the Core (i.e. whatever goes in the ECMA standard). For example it's a perfectly acceptable strategy to use GTK# on Linux, WinForms on Windows, MonoMac on OS X and Xamarin.Whatever on iOS / Android.
On System.IO, indeed there are differences between Winsock and Linux's epoll or BSD's kqueue (i.e. notify on completion versus notify on ready). There are differences between the 2 models, but I don't see that as a problem for System.IO and if you think it is a problem I'd like to read an explanation as to why.
Personally I'm very excited about this announcement. I avoided .NET for years and preferred to settle for the JVM because I do not like building on top of proprietary things. If they are really open-sourcing the .NET runtime, whilst uniting their efforts with Xamarin, that's really good news. Now hopefully the ecosystem around .NET will follow, as .NET needs an open-source oriented ecosystem and needs one badly.
Mono plans on contributing to the effort our cross platform changes to Mono, to make .NET work great on Unix.
Details here: http://tirania.org/blog/archive/2014/Nov-12.html
"ASP.NET 5 will include a web server for Mac and Linux called kestrel built on libuv."
They are open-sourcing the server side code. I think this means your ASP.Net apps can run on Windows, Linux, Mac OSX all from the same open source code base. No worry about Mono incompatibilities and bugs.
I didn't allude to that.
I haven't done much .NET on UNIX but if I was doing so, I'd probably want something a bit more UNIX-friendly than System.Console, though I know it does have the ability to deal with different streams.
Because in that case what's the point? Why not just use Java.
Literally? Well it is visually displayed under it and to the right :P
The CreationTime on DirectoryInfo would have to be faked, and it's not entierly clear if FileSecurity would map cleanly to posix acls, but nothing sticks out as being fundamentally incompatible with linux at least.
C# will port over just fine. But the .Net libraries? System.Windows has little to nothing in it, and right now using things like System.IO.* on Linux and Mac is just asking for trouble.
What are they going to do, hack in System.IO.* Linux support after the fact? Or just add Linux.IO.* which is even more of a hack. In either case you're going to get very messy very fast.
The .Net libraries absolutely could have been designed with cross platform in mind, for example if they put the IO libraries in System.Windows.* and several of the other Windows-specific APIs.
As it stands the .Net framework/libraries are very Windows locked. So much so you'd almost have to scrap them and start over to make it more platform agnostic.