> It's a shame Git doesn't have any tools to enforce that distinction.
Because, by design, Git can't ever know. Example one: a read-only repo can be fully cloned, meaning that all the branches therein should technically be "public". But the cloned repo is read-only so there's no way to add metadata to its branches. Example two: a developer "publishes" her entire repo to a wholly private offsite remote at the end of each day as a backup mechanism. All branches should be marked "public", but that would be wrong since they weren't exposed to any other person. I've recently worked in a shop where all / branches in the main repo were considered logically private unless by prior agreement. Publishing was defined as merging to master; rebasing a logically private branch was perfectly OK (and frequently mandatory).
More to the point: it's not git's job to be overly "smart", especially in ways that require mind-reading. git provides a powerful "algebra of version control", where at some point even the "porcelain" commands can really be seen as "plumbing". In this light, I'm all in favor of higher levels of workflow porcelain. In fact, many larger teams I've worked with accrete such a layer out of necessity. Communicating and performing policy as folk knowledge eventually fails to scale, and tools pick up the slack. So the workflow you describe could be encoded as the Opinionated Policy of a tool on top of git which fills in the missing info in the scenarios above.
This reveals something I find disappointing about TFA: the lack of design exposition about its approach. Also, it appears to be trying to address VCS design without actually talking at all about what's known about the problem space to date. IMO this stands in stark contrast to the current generation of DVCS tools where the players (git, hg, bzr, darcs, etc.) each communicated around a set of concrete lessons learned from prior VCS systems.