> I appreciate that you want to be careful not to saddle asyncio with too much
> baggage, or that you don't feel Controller is significant enough to generalize
> and put in the package.  Perhaps a middle ground would be to label parts of
> the asyncio API provisional, and add Controller to that?

Thing is, when asyncio was provisional, we still couldn't significantly 
change it or break it.  Never in asyncio stdlib era had we removed or 
redesigned some APIs.  Only small additions and bug fixes.  And honestly,
maintaining something provisional and changing it in bugfix releases
is too much stress: we managed to break `loop.connect_socket` once
because nobody tests bugfix RCs.  It was broken for ~6 months.

IMHO: the design of Controller is currently incomplete (see one of my
previous comments).  Even in this thread two other core devs raised a 
question that the API isn't generic enough to be part of asyncio.
Right now it's not flexible and tailored for one specific use case. 
Should the user need slightly more, they will have to copy/paste it, 
or, worse, inherit from it and use its private APIs.