"Anope can be interacted with via RPC"... Yes, Anope 1.9. That's the development release, though. As much as I'd like to share your idealized view of IRC becoming a better place (except for the fact that I definitely wouldn't want to create an IRCd from scratch these days -- linking protocol and especially these goddamn CAP negotiations are just as bad as doing SSL from scratch. Who had the idea of message intents anyway?), fact is that the majority of networks that use Anope (and there are, due to the fact that quite a number of admins believe that levels are easier/better in some way or that Atheme is too much work to set up) use the stable 1.8 version.
Unlike the 1.7 dev version, 1.9 has not been widely adopted. This is mainly due to the fact that Anope 1.8 does just nearly enough out of the box to be still considered modern services, it's more hackable due to being coded in C (writing a module in 1.8 is definitely easier than in the C++ using 1.9 version. It's also easier to make it a complete fucking hackjob in 1.8) and has a bigger modding community (see http://modules.anope.org/ for pretty simple proof of that).
Additionally, it's still a mystery to me how IRCv3 works as an organization. It's described as a "meritocracy", but who is calling the shots in the end? You, nenolod? If so, then I'm not sure if the description shouldn't be rather "oligocracy" but that's pretty bad for the image of anything these days.
Furthermore, I would like to point out that, while four major IRCds are part of IRCv3/implement it, a big part of the implementations (especially so in UnrealIRCd) have actually come from people in the working group (namely you). While that in and of itself can hardly be considered a bad thing, it does lower the bus factor for future changes to the protocol to... precisely 1.
I do, however, agree with your belief that IRC needs a change, but I believe this is heading in the wrong direction. This is just cleaning the protocol up a bit. What we actually need are radical changes, which you'd need to discard all the old diehard IRC brigade for. Analyze what is currently popular: Xat, Facebook, IMs. Observe how two of those are web-based. Does IRC have a web-based client? Yes, it does. Mibbit, qwebirc and KiwiIRC (as well as IRCCloud, but they are absolutely uncooperative with any network). Mibbit sucks downright and is missing the oh-so-important colors to today's generation for the most part. qwebirc is tied to a network each. While that might simplify the handing on the user's part (one website for one network), it still sucks as a client (same color issue as Mibbit, even) and the entire concept of a network just rapes the minds of users. Users today don't know and they do not WANT to know that there are multiple IRC networks. They just want a chat room. Centralization is key. You can't talk of "a Xat chat" or "the Facebook chat" or "ICQ" or "MSN (Messenger)" in the same way you talk about IRC because the decentralized nature is included in none of them (though, if Jabber had found broader adoption amongst non-techies, which will not happen because of this precise very same argument, that would be a basis to work off). KiwiIRC looks promising, but no network has webirc blocks for them yet. Facebook wins because everybody else is already there, not because their chat technology (or anything else for that matter) is particularly innovative or good. Speaking of centralization, having multiple clients and networks is just even more confusion for new users. There is no "the IRC client" and there is no "the IRC network". That is not what users want. Janus links are a step in the right direction (as ugly as they may be), but not a solution.
On the topic of webirc blocks, banning people on IRC is an ordeal. It is a brutal pain in the neck. Other systems may require and enforce registration, so banning is very easy: Right click -> Ban. Or at least they abstract the banning itself away in some manner. You can't do that on IRC. You'll first spend some time telling people about things that should have long since ceased to exist: idents and hosts (and of course, reverse-resolving IP addresses. You can't tell me anyone is familiar with that from the get-go) and then the nick!ident@host format. This is just overly complex.
Another issue IRC is suffering from: Terminology. Oh, so much terminology and so much of it deprecated today. Channels? Chat rooms. Nick(name)s? User names (but that doesn't work because some IRC networks use user names for identification on their services. The lack of services on some places is even more confusing, not to mention that all services work differently in some subtle ways, as if to just confuse the user). Hostmask? Hostmasking?! Cloaking? vHosts? Channel and user modes? Channel and user settings!
Then there is always confusion about the word "network". Users believe there's always only one server. That's just silly, though, but can't be helped because that is how games and other things function quite often. Then we have the universally accepted terms of "administrator" and "moderator", possibly "owner" as well. What does IRC have? Owner (but not enabled by default on all networks, see Rizon, or possibly non-existent because the server admins/the IRCd coders don't want to support it), which should not be confused with founder status on services though, administrator/protected (which has two names to begin with and is also not to be expected/enabled by default on all networks), operator (can we just call it moderator, please?), half operator (Call it assistant moderator or something?) and voice (...No, this has no place in a modern terminology. Throw that out.). Not to mention that the symbols for these aren't the same everywhere, but only a minor case: Networks without owner use ! for admin as the prefix, other networks use & if owner is given. These prefixes are another problem, though. They're abstract. While IRC clients try to have some happy and shiny symbols, they are not the same everywhere, being the bane of any helper on IRC.
And what's with this talk about SSL or SSL certificate fingerprint auth? Way to confuse users even more. SSL should just become either standard or be discarded entirely as per http://www.quakenet.org/articles/99-trust-is-not-transitive-or-why-irc-over-ssl-is-pointless.
So, in essence, you are working on a nice thing, except you aren't solving any of the actual issues why IRC hasn't been able to grow.
