Your right, i missed some stuff in my skimming
This rest is not in response to @rlkoshak, just a general comment, and I appreciate @rlkoshak valuable comments in this thread.
My main concern is that Davids proposal seems to be a UI based approach to the detriment of a text based solution. GUIs tend to have limitations when you trying to represent code graphically, I see crontab format being discussed in this thread and the challenges in getting a gui that can represent all the options available.
How will we help users debugging a rule in the openhab forum with the new implementation, 4 or 5 screenshots that show how everything is set?
Changing to a different rules syntax will mean all the current knowledge base of how to do things will become void. I still see references to OH 1.X ways of doing things when I search for how to solve stuff. So I am sure the OH 2.X stuff will stick around for a while causing confusion.
A language converter would be nice, but i suspect it will end up being too complex given the current development constraints, so will be dropped. Moving from OH1 -> OH2 was painful for me, I suspect this change will also be as complicated and mean learning a new language. I have been using openhab for a while and only relatively recently did I work out that openhab rules are not the same syntax as java ( it does look very similar so I had just assumed it was since openhab is written in java) and instead use Xtend, and then how to do bitwise operations in Xtend. So having good documentation on how to do it will be vital, with lots of examples
I would strongly suggest that we have a way to support power users that want to serialize and load their data files in a way that can be controlled via source control. I would really like it if an entire OH system could be cold booted from text files. I have had to rebuild my entire install from scratch multiple times. If i could control everything via a text file then this would have a been a simple exercise. Instead I ended up removing everything then discovering it via the inbox in paperui, set the name, set the location, etc so it was back the way it was at the start from paperui point of view.
while I see the desire to remove the OH1 code, I don’t think that justifies the desire to get rid of the of a way to configure everything via editable text files. This is a very powerful feature for the power/advanced users. I think it would be worth investing in a UI/extension that replicates and extends the watch file functionality via a standard APIs.