yes, that is part of what I call a problem in the long run. It _needs_ doing, because it is separate forks.
There is no way to "just use" mwc-8bit code directly because:
1) everything is a forest of #ifdef (here it's all compiled and and configurable at runtime)
2) drivers/control code is all mixed and there's no attempt to have any sort of abstraction layer - particularly bad examples: mag and baro stuff
3) 8bit shortcuts are done all over the place - 16 vs 32 bit multiplies if expected value < 65000 etc.
So not all features from arduino-mwii make it into stm32-mwii. Last I looked the entire LCD & telemetry stuff was not there.
LCD is unnecessary because of serial console. It would be basically duplicating all the same functionality of serial console and STILL wouldn't be able to be used as-is because there are a LOT more parameters to configure. For example I'd have to hack in way to change motor mixer or any of the other settings that are only exposed by serial console.
Besides, there is no 'backchannel'. New features from the stm32 fork have no designated mechanism to become part of the arduino-mwii in an orderly fashion.
It's a rewrite for proper hardware only reusing basically bits of control code. Any improvements, if any, would be made with assumption that the hardware is capable so adding an extra sinf() in the main loop doesn't take a week of deliberations and confirmation that it won't affect loop time on atmega168 running at 8MHz. As others said, the code is open and you're welcome to take back ideas or features - I'm sure mega2560 users would like to have a working serial console and all the settings configurable instead of having to recompile stuff. Or heck, forget console and just add them all to LCD if you're into that.
.. and yeah, MS5611 is now officially supported and autodetected even if it's on the same address as BMP085.