But it’s very different! Let’s compare to openHAB1/knx1:
Rollershutter ItemOfChannel1 "My roller shutter [%d %%]" {knx1="GA1,GA2,GA3"}
knx1 wants GA1 to be MOVE, GA2 to be STEP and GA3 to be Position.
If you don’t want to set GA2 at all, you can’t just omit the parameter, but you have to set the DPT for each following parameter (in this case 5.001:GA3). I’m not sure, if it’s even possible to change the order of the GA even when setting the DPT explicitly (and it’s the same for GA1 and GA2 anyway, so openHAB could not decide which is MOVE and which ist STEP)
Now in knx2 there is an explicit assignment for each parameter, so it’s not possible to mix them up anymore.
Type rollershutter : channel1 "My roller shutter" [upDown="GA1",stopMove="GA2",position="GA3"]
Yes, you have to type more characters, but this is way more readable than in knx1.
Yes, you have to link this channel to the item as an additional step, but with VSCode this is done with two klicks, and you could do it even without any textual configuration (Paper UI/HABmin/karaf/REST/…more to come).
Well, there are current bug fixes for other legacy bindings, and even new functionality, but to be honest, knx1 with openHAB2 is not as stable as it should be, and it’s not possible to change this without breaking knx in OH1, so, at least for knx you’re right 
nonetheless, OH1 is not end of life yet.
Well said… did you ever encounter such updates in ANY software?
Well, sometimes… but most of the time updates make things more complex, even for configuration, just because there are new possibilities.
When speaking of knx2, I see a more strict definition of channels, and it’s more clear where to put all those GA for the channels.
In question of -control channels, yes, it’s a pity that I have to define two items/channels for the very same thing, just to receive commands from the bus, but if that is the price to have a stable knx addon, I’ll bite the bullet, and to be honest, there is a difference between getting a rocker activity and the corresponding actuator state, so yes, one has to change old rules, but it’s correct and there’s not more complexity but only different triggers.
I didn’t want to be rude 
and I’m no developer but only end user, it’s my point of view. I’m an openHAB user since OH1.0.
I wasn’t pleased to see an additional layer (things), but in the end I did understand why this step was taken.
I’m pretty sure there will be no step back because openHAB2 is developed with eclipse smarthome, and eclipse smarthome is maintained not only by Kai, there are commercial products using (and developing) eclipse smarthome as well.
So yes, in the end it’s “Take it or leave it.” but please, don’t be offended. I don’t want to offend anyone!