I used it while it lasted and I could have gotten used to it. Maybe I even kind of liked it already. Well, because it caused unexpected problems, there could have been more problems lurking. And then there were those conceptual problems.
It’s a pity that maui’s work couldn’t be used. I hope there comes a next time.
However, I see as a recurring problem with KiCad developement that the developers don’t seem to test their changes even in obvious ways. On the other hand I understand that, but is it too much to take a break before publishing the changes, thinking for a minute what could be affected and just play with it for a while? I often - well, sometimes - see bugs which should have been found with very basic trivial use cases.
It can be argued that that’s why the nightly builds exist, but trying out the nightly builds would be more tempting if we knew that it had a little bit of routine preliminary testing before publishing.
I don’t mean we all wouldn’t make mistakes, I would probably do the same (maybe will do if I ever get to KiCad coding) and in general the “develop quickly -> publish in nightly builds” system works, but sometimes those problems have been a bit too obvious. This is of course especially true for the stable branch.
Don’t get a wrong impression - I appreciate all that work very much, and I myself try to do my part when I test the builds. It has also to be remembered that there’s much going on in KiCad development and mistakes, sometimes basic, are inevitable.