We manage the cleanup issue by defining a "removal branch" that cleans up the feature flag at the same time the feature flag is introduced. This sticks around as a dormant pull request during the lifetime of the flag. It's not much overhead when this is done early. Cleanup does become painful when the code's not fresh in your mind.

Note that we do feature branches as well as feature flags-- trunk vs. branch based development is orthogonal to using feature flags.

For the most part, flags are independent. When I first started using DVCS (back in the Bitkeeper days) we all thought that merge conflicts from doing feature branching would be a headache, but this didn't end up being the case. I've found the same with feature flags. While it's possible for flags to interact poorly, or to introduce "dependent" or nested flags, it hasn't been a problem for us in practice.

This seems to scale, too-- I haven't heard this to be an issue in practice at larger orgs (Etsy, Netflix, etc.) that do feature flag-driven development.

This is more than just the technical capability. I've been on teams that insist they are completely unable to iteratively develop and deliver big features. As a result you end up with huge impossible to review patch drops at the ends of months of work behind closed doors. It's a disaster every time.

I'm still struggling to communicate to people how to do it and what the benefits are.

But the real power behind the idea is not the ifdef piece, it's the idea of dynamic, context-aware configuration. You've got a user-friendly tool that can control the code paths being executed in your application without restarts or redeploys.