In a shallow repository, boundary commits have their parents hidden and look like root commits that added every file. Reverting one deletes every tracked file; in a --depth=1 clone, "git revert HEAD" empties the working tree. Nakul V S's v1 added a check in do_pick_commit() and an --allow-shallow-boundary flag.
Phillip Wood's review raised a problem with that placement. Nakul reproduced it: "git revert <tip> <boundary>" reverted the tip, made a commit, then failed on the boundary and left .git/sequencer behind. Nakul also told Junio C Hamano that v1 was written with only "revert" in mind and did not consider cherry-pick or rebase.
v2 does the check where each command builds its list of commits, through one shared helper that holds the error message. If any commit is a boundary, the command refuses up front. No commit is created, HEAD does not move, and there is nothing to abort. "rebase --apply" does not use the sequencer, so it gets its own small check before HEAD is rewound. That check does nothing in a non-shallow repository.
The escape hatch is narrower in v2. --allow-shallow-boundary remains for revert and cherry-pick only, and rebase always refuses. Nakul said it was added out of caution and offered to drop it if reviewers want no escape hatch. The flag is also out of the synopsis now.
Nakul left "git commit --amend" alone for now because it takes a different code path. The thread has not yet settled whether the flag stays or how the new check should be tested.