you're right for the need in allowing more knx based protocol. be sure i am aware of the limitations of the lmce EIB.
however, i still don't see the interest in linknx:
giving a lamp another address (the state address group) is really not hard at all. you just go int the template in the webadmin, and instead of 6/0/1 your type 6/0/1|6/1/1 . then the config file is given both address
then, when your EIb part of lmce gets an order to the lamp it only reads "i need to send a COMMAND_POWER_ON " to the lamp, it gets its address(6/0/1) and then writes to the bus
on the other side, when the EIB part of lmce gets a telegram from the bus, is parses every peripheral it has been given the config, and according to that peripheral config, may send a message to the router (eg, when the lamp is switched on, it should send a EVENT_STATECHANGED 1 from the lamp DCE_id to the router. ). actually that is not yet the case, but it is really very easy to do(i had done it on the elder version of the source i had).
then one shall modify the LightingPlugin so that it recognizes the event from the lamp. the DCERouter actually doesn't keep the state of the devices in memory, but the plugins can: so you need to handle light events in the plugin, to 'centralize' them: thus the orbiter can ask the lighting plugin if the devices are switched on/off, or their %. and you may prevent the lightingplugin to listen to write orders on the lamp's order groupaddres, and instead make it hear the lamp's return groupaddress.
now, we only need to make the lightplugin handle return address instead of order address, and the lmce able to send/receive through knx. it is already able to make some discussion, but i have to let lmce communicate through other supports than com port(say, usb, ethernet, ..), plus let EIB send messages back(that one is VERY easy). for the 'other support', i am trying to implement eibd atm. but i have some matters with the source code atm..
so, maybe you could tell me how/what is linknx supposed to implement?