Simultaneous drawing by different APIs is not a problem only for "WebGL" (i.e. OpenGL). Lots of other APIs are implemented partially or fully in hardware these days: DirectX, OpenVG, etc. Adobe is even moving towards implementing Flash via OpenGL ES. Simultaneously using any such APIs requires synchronization points. In the example you gave, canvas.getContext would provide a synchronization point, but what is to prevent the application from keeping the context handles around in variables and arbitrarily switching between them? The spec would have to document the synchonization requirements and provide synchronization primitives which would make it more complex.
On the implementation side you previously stated that it is not that difficult to implement simultaneous rendering in a way that doesn't hurt performance for applications that do not use it. Actually, absent some up front indication from the application that it will stick to pure 3D, it will be impossible to do without loss of performance for every WebGL application with some hardware/GL driver designs. So some API is necessary to allow the application to inform the implementation of its intentions up front requiring further spec. changes.
I think we should not support simultaneous rendering by different APIs at the first release. We can leave the door open so if there is great demand for the feature it can be added in a future release. A restriction now that canvas.getContext() destroys any existing context, thus preventing simultaneous rendering, can easily be relaxed in the future without breaking any applications.
Gregg Tavares wrote:
begin:vcard fn:Mark Callow n:Callow;Mark org:HI Corporation;Graphics Lab, Research & Development adr:Higashiyama 1-4-4, Meguro-ku;;Meguro Higashiyama Bldg 5F;Tokyo;;153-0043;Japan email;internet:firstname.lastname@example.org title:Chief Architect tel;work:+81 3 3710 9367 x228 tel;fax:+81 3 5773 8660 x-mozilla-html:TRUE url:http://www.hicorp.co.jp, http://www.mascotcapsule.com version:2.1 end:vcard