As Luke mentioned I took this approach with my Resource Gallery module: http://yuilibrary.com/gallery/show/resource

Y.Resource is about creating a RESTful HTTP client API.

Luke where you talk about var server = new Y.IO({ config }); I think the right breakdown is at the HTTP Resource level; this is what I did in Y.Resource. So when creating a new Y.Resource({ config }) you're configuring the object to match-up with the server-side HTTP Resource it's communicating with.

Another benefit with the instance-based approach is the ability to create an instance and pass it around to other objects which could make method calls on it. I've used this approach often with Y.Resource, creating instances and passing them to Widgets (as attribute values); this way the Widget doesn't have to be configured with all the details of the IO config.

If by HTTP resource, you mean a specific web service, then yeah.

The breakdown needs to be fleshed out between what is configured per instance and what is passed as arguments to send() (or whatever that method would be), including transaction-specific configuration/overrides. I can see instance configuration being defaults for generated transactions, and maybe a sig like send(data, configOverrides) for per-transaction configs (similar to what you have in Resource).

Async form support seems like another opportunity for an instantiable class. But maybe that would be better represented as plugin to a Form class.

To preserve backward compatibility, IO would have to know when it is being called as a static constructor (current operation) and when it is being called as an instance constructor.

The compatibility step is quite important, as implementing instantiable IO will break the synchronous request model (and, abort and isInProgress methods for asynchronous requests), unless instantiable IO was facilitated through another, new constructor.