But you're asking for this when there is a code fork that will not be merged, or it's simply not sure it will be.
My take on the thing is that once TFTD support will be in beta and only bugfixes will have to be stapled down....that could be a good time to pull most of the feature requests for OXC, at least concerning the UFO part.
I see no reason to fork away at this point risking incompatibilities with TFTD specific code.
Of course I do NOT mean "do not work on this", but I'd play along the lines of doing something you're confident it will be POSSIBLE to merge, and not divergin already.
Of course I don't know if this is at all possible, eh.
I may have misworded what I meant - I think that things that conflict or potentially conflict with vanilla OpenXcom mods probably shouldn't be priority. Also things that can potentially change ingame mechanics in a way that original behaviour is no longer possible with a port. I think good port for a game should be able to let one play the game in its original state as close to vanilla as possible while also supporting diverse mods.
I don't want a both way compatibility - thats nonsense and I know it. But it shouldn't end up with two completely different ports with two exclusive sets of rules.
It's similar situation like with ZDooM and GZDooM - ZDooM focuses on new mechanics and GZDooM focuses on graphics while retaining compatibility with ZDooM. So you can play ZDooM mods with GZDooM but not all GZDooM mods with ZDooM.
The view distance mod is backward and forward compatible with regular version of OpenXcom.
I know, I checked what it should do and I wanted to try building it last weekend but I had some problems. I probalby didn't merged the branch correctly. I am not used to Git. Or programming.