he just has to make the next request before you do

Something as simple as a confirm page becomes an unsurmountable obstacle to the attacker.

So he's made the request before you do, and updated your cookies. Now what ? He has to get you to let him ride again, and he doesn't have enough info to construct the request he needs anyway.

If you chose to invalidate each older nonce after new requests, you’re going to have to store them. Why not.

which are a) stored

You only store the latest. There's no requirement that you support tabbed browsing in your logged in site, for one. If what the guy is doing is surfing pics he doesn't actually need to be logged in. If what he;s doing is banking you don't need five tabs open.

Moreover, you can serialize the requests like anything else, after all simultaneity doesn't exist in the real world. For that matter you can simply log him out if you get requests faster than one a minute, why not ? Nobody said security is convenient to any arbitrary degree of convenience. Let the user learn this.

and isn’t enough to protect from eavesdropping

There's no way to protect http from eavesdropping, it's designed to be and functions as a plaintext channel. You can either implement end to end encryption like MPEx or else learn to live with the fact - the fact that your communication is plaintext. No matter what you do. A fine example here is the fate of the SR pile of fail (and for that matter : some of the latter scriptkiddies vieing to fill that void of fail actually came up with models such as "paste your gpg secret key in here for security". Not kidding!)

SSH doesn't lie to you. When you connect for the first time to a server, it doesn't accept the certificate, and displays the fingerprint for you to check. Browsers trust external services, where any of them has ultimate authority.

SSH allows you to use a password, or better, a client side-key. (Actually, you can do even more custom stuff if you want.)
SSH is stateful, though you can use it for one-time requests if you want to.
Browsers have nothing of the sort; users have to authenticate with things than can be replayed.
Added bonus: multiplexing.

If you chose to invalidate each older nonce after new requests, you're going to have to store them. Why not. However you're probably going to have to handle users opening multiple pages at once, and having multiple browsers (not that hard, store a cookie to distinguish which browser is which). And in the end, the attacker can still make a request instead of you, he just has to make the next request before you do.

In the end, you have a system that is overkill if you want to prevent stealing the cookie from the computer, and isn't enough to protect from eavesdropping; the time based tokens are enough and transport security should take care of the rest.

Any better solution would require browser cooperation or JavaScript.