Thanks for the reply, @hek.

1. Maybe here we can take things one at a time. For a first step, would building the GWs as MQTT allow connections through a broker such that multiple GWs will work?

2. "Arduino compiler" is bad shortcut name. I meant that there is some transformation arduino does to the code before it reaches the gcc compiler. This is what i want to avoid and have my code work with gcc directly, even if using arduino core/libraries.

Any thoughts on this?

Thanks for the reply. Here is what i have in mind in more detail:

1. Say i have a NRF24 and a RFM69 and RS485 communication locally. Another WiFI gateway at work with some sensors to check if the colleague is really watering my plants as it should. Gateways should have a link (IP prefferably) with eachother, so that any node can send a message to any node. This should not go through a central controller. So far i am splitting the node address space into few ranges, each one for a GW, but would say gw.node.child would be a better addressing scheme.
2. If you were to import the arduino project in something like atmel studio (or eclipse or other ide) that copies the arduino core sources and then the libraries and tries to compile in regular c/cpp, this would not work. My desire is to be able to nicely see and change the underlining HAL layer, because i really like to juggle with HW resources. Having used the SAM lately with ASF i find it way more intuitive to change things like which SPI to use. Platformio is of no interest, since it is still calling the underlying arduino compiler with it's special programming language.
3. Some things are simple: find a way to say what is the light level as well as that motion is triggered. Fundamentally i want to create new types on the fly, independent of the middle library. At an extreme case: upon startup a child should say: my packet contains a boolean, a float and another byte. The controller software then gets 3 channels. Basically, I want to get rid of the strictly defined V_ and S_ and create definitions based on fundamental data type. Between this implementation and yours there are a lot of other combinations and where the compromise falls it is hard to say.
4. I built some nodes, using nrf24: dimmer, dimmer with rotary, motion, button and gateway. It seems that if the GW disappears, even adjusting the dimmer from the rotary is chaotic and mostly does not work. The motion sensor also does not seem to resume normal operation should the GW resume functionality. Might be some small changes required, but based on request 1, ideally any node should be able to communicate with any node, on any GW, and in the case of a missing GW, the core functionality should stay (be able to control the light with the local switch).

I hope this makes things a bit more clear now. Thanks for the support.

I have been working on my own framework for sensors, I am almost in the same place, but with a lot of shortcuts.
Considering the community around MySensors, I thought there there would be a greater opportunity to grow if we work together, so I could dump mine and continue developing here.
However, there are some things that I want from the framework, so I am interested developers' intention to include such features in the near future:

1. Serious multiple gateway support, with both multiple local and multiple over the internet gateways.

2. Making the code C/CPP rigorous, not Arduino style so it can be used on different platforms which offer full HW control and code transparency.

3. Message merging so multiple messages can be carried over the same packet. Custom, on the fly defined types is a bonus.

4. Gateway-less operation.

5. What are the long term commercial intentions of mysensors?

Of course, I can help implement 1, 3 and 4 and quite a few other features I am interested in, but number 2 is quite blocking, as I have no intention to spend time upgrading each new release, so it is more of a change that has to come from the core developers.

Cheers!
Bob