I would like to present some arguments against having the SSD with the wayland even as an optional extension. I hope these arguments will help during internal debate when it will occur.
I will try not to repeat GNOME's "CSD initiative" article and I will address SSD proponents' arguments.

There are a number of reasons some people want to have such extension, I will try to explain why they irrelevant of will not work.

• Having SSD functionality makes client development easier.
• DE can use window's header to show some DE's information, to add some controls for window-related DE's functions (like "always on top" or per-window keyboard layout switcher)
• DE can have mode when it shrinks or hides decorations to save screen space.
• (aestetics) We need to restore "same decoration for all windows" principle
• (aestetics) Decorations should obey system UI theme.

Hope I haven't missed anything.

Having SSD functionality makes client development easier.
Not at all. As you already know, GNOME choose not to support SSD. As well as Weston. And there will be tons of another DSes which will not.
The whole point of Wayland is to have some simple enough protocol, to make possible to implement a display server from scratch. So, even if GNOME developers somehow see the light, there will be other wayland servers, which won't support. It will never be safe for a client to rely on having some decent decoration on the DS side. So, each wayland client app should know how to draw it's own fallback decoration, maybe ugly one, just to have something to move/resize/close window. Clients have to support two different code paths. Client app, trying to behave nice, will have to support different layouts, one with CSD, placing tools on headerbar, and one for SSD, with separate toolbar. And all this to solve minor problem.
Even without any toolkit, CSD, from developer's perspective, requires almost same work as creating 12 buttons. 9 buttons (4 corners, 4 sides, and header) should react to mouse down and send a command to DS, and 3 (minimize, maximize, close) should react to click. Not a big deal.

DE can use window's header to show some DE's information, to add some controls for window-related DE's functions (like "always on top" or per-window keyboard layout switcher)
And what to do with CSD windows? Don't they need same information and same controls? If CSD windows can live without those controls, maybe they aren't so necessary, and were created in first place because there was plenty of empty space within window's header?
I agree, there must be something to allow DS to implement it's functions. I think soimething like "show window's context menu" command on headerbar right click.

DE can have mode when it shrinks or hides decorations to save screen space.
Yes, window's header is just waste of space. Everybody knows this. The Unity 7 had an option to use a dirty hack to move an app's main menu to window's header. But special headerless mode within DE is not a solution. No point to hide header of a message box, for example. Application itself must know if this concrete window needs space, and app can achieve this using CSD or/and fullscreen mode. That is not DS's job.

(aestetics) We need to restore "same decoration for all windows" principle.
Well, same decoration for all windows never was an intended goal. This is just side effect of another architectural decision. In Windows GUI subsystem had builtin GUI toolkit for all controls, including window's borders and headers. X server have no blessed GUI toolkit, but X architecture has a separate decorator (windows manager), no wonder all windows had same look. Most stylish and fancy apps never use default decorations, and users like this. Even Microsoft with their "serious business" office pack had always use some custom look and feel. You don't have to be more saint than Pope.


(aestetics) Decorations should obey UI theme.
Well, first I have to point that from user's perspective it doesn't matter who draws decorations when DE and window have same theme engine and obey same theme. KDE window running under KDE will look same regardless of where decorator resides, within DS or within KDELibs. So, the only case worth exploring is when DE and a client app have incompatibe theming engines or one of them doesn't support theming. Does SSD fix anything in that case? Not at all. Imagine some foreign app with a dark theme. You don't want header bar which is same for black-over-white and white-over-black windows. So you need another protocol extension which will signal "using dark theme" or even "using theme with these colors". And way to signal DE when user switches in-app theme.

(aestetics, bonus) MDI app coherency.
Only case when decoration coherency matter is within MDI app. MDI App can have several types of windows/widgets.
(a) The main window.
(b) Document's windows which reside within main window.
(c) Detached document windows. It is good to have an option to detach some document from main window and drag it to second monitor.
(d) Floating toolbars.
(e) Docked toolbars.
(f) Docked document window (like tab)
All these must look similar, but not the same. (c) must look exactly as (b), regardless the fact that (b) is drawn by toolkit/framework. (b) and (c) must look almost same as (a). (d) must have compact decoration, have some similarity with (b) and (c), and (e) simultaneously. (f) must look like usual tabs from toolkit, but still resemble (b) and (c), for example have same font, color and similar close button.
There is no way you can achieve this with any sane SSD protocol extension.

So, what's the point to have an extension which solves one contrived problem, does it badly, only for simpliest case, and brings more problems?

You should take this to the Plasma development mailing list, the forum is meant for user support mostly