I think it won't meet with favor if there are cases that require manual intervention for starting the server. That was the main argument for getting rid of the exclusive backup API, which had a similar problem.
In the rare case of a crash of the source database while one or more databases are in progress.
Or even more simply, just document that should the process executing pg_backup_start, and eventually pg_backup_end, that noticed its session die out from under it, should just add crash.signal to the data directory (there probably can be a bit more intelligence involved in case the session crash was isolated). A normal server shutdown should remove any crash.signal files it sees (and ensure in_backup="false"...). A non-normal shutdown is going to end up in crash recovery anyway so having the signal file there won't harm anything even if pg_control is showing "in_backup=false".
In short, I probably don't know the details well enough to code the solution but this seems solvable for those users that need automatic reboot and crash recovery during an incomplete backup. But no, by default, and probably so far as pg_basebackup is concerned, a server crash during backup results in requiring outside intervention in order to get the server to restart. It specifically requires creation of crash.signal, the specific method being unimportant and its contents being fixed - whether empty or otherwise.
