A single code base with half-baked code under feature toggles seems different from "a series of branches manifested in the code itself". Branches would mean there can be different versions of the same half-baked feature that need to be reconciled.
Are you saying that people in this thought experiment would go so crazy with feature toggles that they'd develop several different versions of the same feature, each with different toggles?
Yes it's possible for feature branches to look a bit like feature flagged code, but other than that, the administrative and organizational implications seem very different.
The most obvious being, it's a lot easier to see everything when it's in one place.
The hypothetical is the code is half baked, never completed and obsolete. In TBD, work is required to remove it. If using a branch, nothing needs to be done.
I guess I would hope that some thought or review takes place prior to merging to the trunk, such that the work merged there is suitable to build on, not just everybody's unfiltered shower thoughts.
That, to me, is the difference between committing on a branch and merging back to trunk/main. A branch is just a way to record and share an idea. Merging back is saying with some confidence "this is something we should build on". Feature flags allow you to disentangle that social signal of "we should build on this" from "this works in production".
I'm not sure (and curious) about other ways of working that can fulfill the same collaborative social signaling function.
Are you saying that people in this thought experiment would go so crazy with feature toggles that they'd develop several different versions of the same feature, each with different toggles?