I think the whole deal will be to take what is really stable
If it would be you managing to submit dedicated backport pull requests for code review & integration, great, and you indicated such before... but if it's "I'm developing my own fork as it's most convenient, but feel free to dissect it and copy/paste to ML" this won't work, and you know it.
It's perfectly legit to do it your own way of course, and I'm absolutely grateful for all the 6d work you've done as I'm using it right now - but as time passes & the more the TL code base differs, the more pressing is the need for you to decide for one approach or another.
The only way I can currently see to save this is for you to start submitting small pull requests once you update new ML features to the 7d/600d/6d, like stub addresses or such - so you'd help "maintaining" these for ML and don't just keep them in your fork. If that's covered, surely a schedule could be worked out what features need to reach what stability for a backport pull requests, of course it's fine to work on unstable features in an experimental fork for some time.
However, unless you indicate with action you're going to be a part of the *ML* community, as a long-time ML user I can only side with alex and say the split in the community merits stopping users being confused, i.e. separate ML & TL entirely.
I know maintaining an own fork is much more fun, submitting pull requests is tedious and having them torn apart by smart-a** comments by the big devs can be very annoying as you're not in control of what gets merged. But I do hope that if you should decide to take up the offer to make a schedule for TL re-integration, I can only hope the ML devs will acknowledge that this might not be easy for you and will strive to let you put your ideas into ML - all factual disputes I've ever read about can be mediated or solved quickly.