Im sorry you feel that way, and have to say I disagree in general, but as some attempt at explanation:
This is as mentioned above, very much in line with the work Andrew was doing previously so its design has as you mention been proposed, and has had the previous code available on branches for close to 9 months now. Given this, despite this being a reimplementation (involving less change in a more controlled fashion), I dont think this is entirely out of the blue and it seems like ample discussion had taken place and time to consider it been given.
I can conceed your point about possibly putting it up for review first, although I would usually only take course for something that hadnt been given prior discussion, hadnt had any review, and had some doubt about it. I would stress that this (and Andrews code before it) has already seen weeks of review from myself before I committed it, and again the previous implemtnation has been available for all to look at. Great care was taken to try and ensure consistency of the IO behaviour during the restructuring (which was actually fairly minimal for the 0-10 code path), and no IO features which were present and worked or were being used are being (permanantly) removed. Much of the change that went in was nothing to do with the IO layer alongside work, and is purely to the Java broker or associated dead Mina related features.
The transports are not currently configurable, however as I mentioned above they will again be made so via a final JIRA (quite possibly tomorrow), in similar fashion to the way they were already. I didn't think this small delay was a particular sticking point for the rest of the code given that until these changes were made there were no two interface-compatible IO implementations available to use such plugability.