IMHO, first it needs to be stated that feature flags are only truly useful when you have a process to change the flags that's faster than deploying a new versio

IMHO, first it needs to be stated that feature flags are only truly useful when you have a process to change the flags that's faster than deploying a new version of code. I've seen some environments where a flag configuration deployment is the same work as a code deployment, and so why bother. Also, these things need to be temporary, and you should enforce that somehow. Otherwise, chances are very few permutations are being tested, which makes it hard to use the flexibility you tried to build. Some teams automate this in some fashion... require an expiration date comment, fail the build if it's in past the date, or if you like things spicy, have a bot remove it on expiration. Sometimes you end up with a feature that's done in your code but waiting for something else and you end up with the behavior disabled for a long time. That's not fun, but it's life. Otherwise, I like feature flags to live for about one release... Put it in, push the feature, once it works, remove the ability to turn it off. That should be part of the post-release acceptance process.