Limitation of OpenHab

I'm using OpenHab for 2 or 3 years. I like the fact that there are lots of different bindings. But I find some internal design very limiting. I do not know how to overcome them and I'm looking for a other software (but I did not find another one fullfitting my requirement yet).
The main reproach I would do to openHab (and lots of similar software) is that there is no separation between basic hardware and concept presented to the user throught the UI. It it find when each hardware is linked to a direct concept (a lamp to switch on/off, a window roll to open/close). But I've several instance of multiple hardware that I want to present as a single concept in the UI. For example, my window roll are managed by remotes that I "control" by an electronic circuit that simulate key press and that is itself controled by 1-wire. So, for example, to open a window roll, I've to send a 1-wire command to simulate the press of a remote button, wait 0.3 second and send again a 1-wire command to simulate the release of the remote button. So, I do not want the UI to present the core bindings (ie 1-wire software) but, instead, to have a layer in the software so that I can build a concept for the UI (windows roll with actions and state) that will use lower (raw) bindings to really control it.
With OpenHab, the rules files allow a bit of that. But its language is really too limited to be useful (no way to declare a "window roll" model to instanciate as many time as you have window roll). So, to be useful, rules files should be generated from something else. It's what I'm doing but it is very paintful.

Other limits I found in OpenHab are :
- no way to handle a timed bus. Going back to my window rolls, I've several of them. To put them in the "middle" position from the closed position, I've to send a press/release 1-wire command to simulate a remote key press, wait for a precise time and then resend a press/release 1-wire command to simulate another remote key press. In this schema, the time between the two key press simulation is very important but its depend on the window roll. However, all 1-wire commands must be serialized on its hardware bus. So, I would like my software to be able to manage the list of command on a serialized bus that have timed constraints. I do not want to have to "lock" the 1-wire bus totally when one window roll move (ie I want to start the move of several window rolls before stopping them).
- no management of time wrt the state of object. As not all transitions are immediate, I would like to be able to distinguish the targeted state for a object and its real current state.
- no way to manage priorities in various commands (so that a direct UI order would be taken in priority wrt programmatic orders).

Most of this should be accomplished by rules files but only at the expense of very complicated rules files (so not hand-written ones).
If I so not find another better suited software for my needs, I'm thinking of using two instance of OpenHab: one that will provide me a uniform access to low-level bindings. On top of this, I will write a component to manage "complex" objects (objects that use several low-levels bindings, objects that managed timed bus, objects that have targeted state/real state, ...). And I will perhaps use another OpenHab instance to expose (part of) these objects throuht home-made bindings to the user with OpenHab UI.

The fact that, currently, the OpenHab UI is directly linked to the available bindings is really a big design issue for me.