Hi twiclo, I appreciate your appreciation 
.
With the multiple monitors this is something I also want, my plan was to do it after adding Copy & Paste support. I opened an issue on it on the repo, along with the other planned work.
With the Mod+1 I agree, can you please open an issue on the repo requesting it? Something like “I as a user would like” and just define what you want.
I think someone else mentioned sway and I would suggest looking into it. Tiny-wlhs isnt really in a place to compete with the likes of sway. There are a number of issues even outside the missing features, for example currently it uses pixman as a renderer so its not even getting any acceleration.
The intention of the project is to provide a Wayland compositor that can be configured and controlled in Haskell. I also hope that over the coming months and years it will help in charting a map towards Haskell wayland bindings and a truly pure Haskell compositor.
On feature parity with XMonad being the goal, the answer is yes, and I would include performance with that, but this does not include the config or plugins. On the plugins its simply not possible on wayland, as its a totally different architecture. So most X11 apps have Wayland versions or Wayland alternatives, for example Dmenu has Bemenu for wayland.
Generally with tiny wlhs im torn between a few different directions for what I should focus on. I was trying to just power towards something I could use as a daily driver, but this work is just adding functionality to the tinywl.c shared library to bind to, currently this has ballooned that file to 1.6k lines and likely with the remaining Copy & Paste, Mulitmonitor and tiling support will become unmanageable.
Already the code is hard to wrangle. I have been putting of adding the necessary tests and other supporting work to make the C easier and safer to work with. I have a few options, I could just refactor the shared library into a more manageable setup, and this is likely what I will do.
However in the last few weekends I’ve been experimenting with language-c and other libraries to see if there is something clever i could do. In a perfect world I could move this work to Haskell, but keep C’s performance, code generation seems the mostly likely way to achieve this.
One of the things I was playing around with was working with the C AST. I have a few more ideas I will test this weekend, and I want to investigate what other bindings libraries like GTK did, if I can’t find a sensible path forward I will likely just refactor the C code.
In parallel to this I want to make the library more usable and easier for others, I want to add in a CI/CD, tests, better documentation etc. My hope here would be getting contributions to divide the work load a bit. This is also the reason I want to try and move the work into Haskell and not just writing C.
Im also conscious of long term sustainability it will need good testing and CI/CD, documentation etc and this become more true as time goes on.