I do hope Spectre gets more active development again so can also move towards supporting Wayland. It seems to be a nice piece of C code so would be a pity if that important characteristic wasn't further taken advantage of. However, be several years I feel before X hardly used any more so not really a concern of today - all other new technologies apply whether using X or Wayland pretty much anyway, and X still has advantages as Wayland positions itself to overcome its non-implemented support bits and pieces.
I won't make any comment regarding which I find has nicest functionality and efficient ease-of-use convenience. My feeling is that pretty much any tiling manager can be set up to provide similar efficient use-case functionality. I think most all are potentially very very similar in efficient resource usage (that's how I find it on measurement by the way), where it all comes down more to how your set them up and what bells and whistles you add; very efficient/economical and nice to use anyway - doesn't take long at all I find to master main key combinations. I can't help but feel, for me at least, tiling window managers are near perfect to use in practice - at first they don't feel like that and seem like a bit of a blank screen, but wow, once you get a hang of tiling in conjunction with workspace handling you wonder why you bothered with gui-wizard-driven stacking/floating window managers (and especially when you can also float windows in most tiling window managers - not that I feel much need to usually).
For me, polish, in terms of making sure distro ends up having all the facilities/apps/functionality I want for the way I use my computer (rather than shine and sparkly visual effects) is what is important. That takes work. Nothing against the prettying up either of course, except on older lower resourced machines where I want to use every CPU cycle most productively so they appear just as fast and comfortable to use as my most powerful machine.
It certainly takes time to add in all the expected/wanted overall functionity, including printing, bluetooth, network connectivity matters and so on, and I tend to be a bit lazy with these finishing touches, but once I settle on a distro that always becomes my main objective. Boot matters/techniques are much more of a lower priority side matter to me - I already have preferred main boot mechanisms that work perfectly for my own needs, but of course I do my best longer term to support alternatives (which often involve initrd code support so not work to take on lightly - that being the FR heart I have to take care not to break what works so well).
Best thing for me about KL/FR is that it makes building complex variant distros really pretty simple with no loss of power or flexibility. I never imagined it would work so well despite my best intentions, and importantly, doesn't need much support from me at all really (very little maintenance of the simple core build scripts required in practice). That means that it establishes itself as a ready-to-use, relatively straightforward build system that, amazingly really, produces great products and encourages participation from anyone interested (who don't need much dev experience and plenty helping hands anyway to explain the mechanisms and provide support code and utilities). That's KL.
It is also obvious to me that those who start using/creating with KL/FR quickly gain experience and skill, which is probably the most inspiring result.
