Merge strategy for different feature versions?

Forgot the "for" in the title.

Thanks, this is quite helpful already.

As much as I sympathise with your predicament, I suspect this is more a problem with your development workflow than Features itself.

Probably yes :)
On this particular project I am slowly introducing features. However, a lot is still happening without features.
Also, there is one big and nasty feature around from long ago, when I really had no idea that splitting a feature up is a non-trivial task.

I wish it was easier to split up features, or disable them and keep the site functionality, etc. And then let this split-up travel to staging and production, or to your fellow developers.

Kit specification for Features

Nice thing!
Actually, this describes more or less the way I intend to work today. But, there are still older features around, which do not work well with this spec.

content types tend to work better namespaced

Hm, I don't get it. If I create the feature with features module, everything is "namespaced" (in D6, that is "prefixed") with the module name of the created feature. E.g., for a site where everything tends to begin with "bw_", typical feature module names are "bwf_groups", "bwf_events", etc, distinguishing it from regular hand-coded site-specific custom modules such as "bw_groups" or "bw_events". What more is there about namespacing?

Edit: In addition, if you can find a graphical git client for your environment that supports line-by-line commit and discard (e.g Sourcetree for OSX, which is free), its much easier to do the actual merge on these big complicated merges.

Good idea.
It would already help if git merge would not cut the code at arbitrary positions in case of merge conflict, but consider the brackets or indentation.

don't work on the same features at the same time

Nice thing to ask for, but..
I had the idea that merge conflicts in feature modules are often more nasty than those in hand-coded modules, for some minor changes. Hand-coded modules tend to be more forgiving to more than one developer working on the closely related stuff, if none of the developers does any heavy refactoring or moving lines around.

Edit 2: One other thing I forgot, keep a strict rule that Features are NEVER overridden except while explicitly working on a specific feature. As a rule of thumb, before and after working on a feature, you should be able to run drush fr-all without any problems.

Good one.
I hope we can get to this point once.
For this existing project, I don't expect it to happen that soon.
For new projects, any time.