Sort of? It's my understanding that the Compositor takes the role that X used to (try to) play, handling surfaces and rendering. The toolkit handles the other parts that X had (part-time) role in, i.e. input, and the window manager (which may be part of the compositor or the toolkit) handles...window management, placement, etc.
Kind of. The compositing of windows, yes, it was done in part by the composite extension on X.org. But only at the extent Wayland handles it: it creates several buffers in which the apps outputs their graphics and a common surface where you will composite them, but AFAIK how this is handled is defined by the window manager, and that's why you need it to support it explicitly on X.org.
As for rendering, sort of. I would call it compositing only, since the compositor does nothing at the surface level (except for the composite surface, that is). It instead copies the visible contents and performs any math needed for any enabled special effects. Actual rendering (as in taking the input of the app and turning it into an image) is client dependent, and will most likely be done with toolkits and OpenGL.
As for window management and toolkits, the only part they perform should be window decoration.
As for input, I think it's handled by Wayland (the protocol, not any of its compositors) and the compositor chooses who gets the focus.
Raster, I'm assuming you've brought up these concerns with krh and the likes? Changes needed to core is kind of a red flag...
yes - some of them already via certain channels, and others are really shell extensions which are related to making a full desktop and we'll likey just implement them first then propose them for others to share.
Weston isn't meant to be used in production for one... its the developers playground and testbed for protocol support. Its not meant to be the fastest (read: optimizatized) its not meant to be a fully featured desktop. Its a place for the wayland devs to make sure the protocol works as expected.
There was an idea discussed that basically came down to there will be one shared system compositor, and then Gnome/Kwin/Enlightenment/etc will implement their own session compositor (mutter/kwin/E...something/etc). Not sure what ever came from that discussion...
well a system compositor + a session compositor is an option. reality is all the session compositors (e, gnome, kwin etc.) NEED to be able to drive kms/drm directly without a system compositor. to sit on top of a system compositor is a simple matter of the session compositor becoming a wayland client itself and that is perfectly easy.doable as for e anyway it uses the same toolkit and rendering path wayland clients with elf use anyway, so it's just a matter of saying "be a wayland client, not a drm/kms direct renderer" to the canvas engine. so design-wise it's mostly moot for us.