Again: request forgery isn't an intrinsically cross-domain problem. The HTTP protocol change you provided is already worse than the serverside solutions it proposes to supplant.
Serverside request forgery tokens don't rely on browser behavior to function. They provide a much simpler and more direct security model: to POST/PUT/DELETE to an endpoint, you must at least be able to read the contents of the token. This meshes with same-origin security.
The loss of user agent control is a serious problem independent of whether or not a malicious request is accepted. The fact that the user agent crafted and sent the malicious request at all is a problem worth solving. But for some reason you either seem to believe that it doesn't matter that the UA is acting maliciously on users' behalf, that this is an inevitable consequence of the way the internet works, or that it's such a difficult problem to fix that you'd rather ignore it and focus on the server-side. Or perhaps both.
Personally, I don't believe either of those things. Server authors should certainly take point on battling CSRF. But there is an important client-side piece to the puzzle that cannot be ignored. If users cannot even prevent their own browsers from attempting malicious actions on their behalf, then there is something critically wrong with browsers.
Serverside request forgery tokens don't rely on browser behavior to function. They provide a much simpler and more direct security model: to POST/PUT/DELETE to an endpoint, you must at least be able to read the contents of the token. This meshes with same-origin security.