And there is no issue with having applications running in the background, that's just what the Metro music app does for example.
Music is very different from persistent TCP connections. WinRT has special opt-in APIs that allow specific tasks to be run in the background. These are old API concepts, you can look to iOS as an example of this. iOS has "multi-tasking" as well, and lets you run music in the background, but you can forget about running TCP connections. Metro is likely to be the same way:
"For Windows 8, we started off with a rule that would apply to the large majority of Metro style apps: if an app is not on screen, and the screen is not on, it should not impact your battery life," - [url=http://blogs.msdn.com/b/b8/archive/2012/02/07/improving-power-efficiency-for-applications.aspx]MS on Metro apps
The link in the quote above outlines the specific background tasks that are allowed:
Playing music, Downloading a file from or uploading it to a website, Keeping live tiles alive with fresh content, Printing, Receiving a VoIP call, Receiving an instant message, Receiving an email, Sharing content (like uploading photos to Facebook), Synchronizing content with a tethered device (like syncing photos)
Note that all of these things are not persistent (don't be fooled by "Receiving an instant message", that is likely just using Windows Live over HTTP). You will likely be allowed a burst of TCP. There's a white paper referenced in the article that documents the details, it seems as though there is a bandwidth cap on apps depending on where they are located in the tiles.
IRC connectivity goes against everything the above quote stands for, because it requires the same amount of CPU/resources whether the app is in the foreground or background; you cannot scale back resources when it is in "standby" mode. And we're still
just talking about connecting to servers, not the thousands of other features mIRC has which allows it to do a whole host of things that would break Metro (or have Metro break mIRC, technically).
Well, IRC is a simple enough concept that you would have no issues making a Metro app for it.
Yes, IRC itself is simple. I said this. mIRC is not
just an IRC client, though. This is the distinction. mIRC is not a simple client for IRC, it's a very complex one that would require a whole boatload of special integration to work as a metro app. Even if you could just get a socket to stay connected when an app is backgrounded, you would still not be able to easily access the scripting engine, a very core part of the client. Timers wouldn't work, events wouldn't work, DLLs wouldn't work. Things would break in tremendously weird ways.
For mIRC to work properly as a metro app it would have to be simplified and downsized significantly to fit in-- not only in terms of UI, but functionality. You'd end up with a product that is basically not mIRC. And what's the point of having an mIRC for Metro that is nothing like mIRC for the desktop? It might as well be any other IRC client, and I'm sure someone will make one eventually. Given how overloaded Khaled is just maintaining mIRC for desktop, it would take years before you'd see a properly functioning metro version of mIRC (with or without its core functionality)... so there will definitely be competitors by then.
I guess my point is; if it's really simple to make an IRC client for Metro (and it probably is), then you should make it; you will probably make a lot of money if you do. And don't worry, if you don't, someone else will.