CSRF and double posting

blah blah blah

It's one thing to disagree because of misunderstanding or lack of knowledge, but to dismiss facts as "blah blah blah"?
Are you seriously being that ignorant?

What does the "A" stand for in AJAX?

This is in no way related to CSRF. What a moronic straw-man, indeed.

What does the "X" in "AJAX" stand for? XML you say?
Are you going to call everybody doesn't use XML a moron?

If you're making synchronous AJAX calls you've failed on so many levels I don't even know where to begin.

Because you're the judge of everything? Features are features, they all have use cases.
Even if it is a bad feature, you're exaggerating big time and it's beside the point - I've stated what asynchronicity is what creates a problem for you, not that you should use blocking AJAX calls.

Again, nothing related to CSRF.

I'd love to see how you manage concurrent AJAX requests with this enabled since CI's implementation uses a single valid token.

Still, you don't understand how the CSRF protection mechanism works and/or what concurrency means. You don't need to do any extra work for concurrent requests to work.

What matters is the cookie value at the time of submission. If it was possible to have 1000 concurrent (meaning: simultaneous) requests, they'd all pass, because they would all carry a matching cookie + form token pair.

I'm astounded I even had to say asynchronous as only a complete moron would send synchronous AJAX calls.

I'm astounded by your insistence that how AJAX works best is somehow a security consideration.

The spec is even deprecating this behaviour and for good reason.

I'm sure there's a good reason for that. In fact, I'm sure there's more than one reason.
However, you talk too much smack and present yourself as a credible authority on the subject, while not showing much substance, and I'm not convinced that you know that "good reason" yourself.

Let's lock browser threads! Yay!

... I don't even want to know what you mean by that.

If you aren't vulnerable to XSS attacks, can you provide an example of a security hole created by using a single token vs a token that changes per request?

First of all - per POST request, not per any request.
You know you're cherry picking here and by doing that you're ignoring a very reasonable trade-off, playing up "hard to implement" types of problems that you create for yourself, and that your whole argument is based around.

Second, "if you aren't vulnerable to XSS attacks" is a somewhat valid point to dismiss immediate threats, but also a very sneaky way of trying to control the narrative. We're talking about information security - consider all cases, don't assume that nothing will break; assumptions are the evil.

Third, nobody has said that not regenerating automatically creates a critical security flaw, like you're implying.
It's mitigation for lesser evils, but evils nonetheless.

And to answer your question: CSRF tokens can not only be stolen, but also planted. That is way worse if it happens, because even if I'm charitable enough to assume that at least you have a sane cookie expiry time configured, an attacker can override that and make you a target for years.

I'd love to hear it because apparently the security company we paid to smash away at our app for 3 days straight wasn't able to find one.

I don't know your app, but judging by your earlier suggestion of X-Frame-Options - if you use that, of course they aren't going to find an issue.
I don't know the company, team & expertise level of those who audited it - there are a lot of crappy security auditors.
I don't know what you consider a "hole" and how honest you are here - many potential issues are raised as "info" or "warning" items on audit reports. Judging by your behavior so far, you may be twisting this all kinds of ways.

And please, don't say "in theory if they get your token"... if they can steal it once they can steal it 100 times.

You don't know that.

I may stumble upon it by accident.
I may read it once while having limited-time access.
I may not be able to re-steal it less time than it takes to regenerate.

...

I said concurrent AJAX requests, you can't send concurrent synchronous AJAX requests since JS is single threaded so I'm not sure what else to take from that. Yes you can multi-thread with web workers but the DOM paints in a single blocking thread.

...

I'm not arguing the theory, that would be pedantic

Oh, now we don't want to be pedantic? What happened to the A in AJAX?

Here's something pedantic: JS and DOM aren't single-threaded, and the latter is not even a relevant term. Browser implementations may be single-threaded - that's a different thing.

but in reality the limits imposed by per request CSRF tokens simply aren't worth the theoretical security advantages.

So we went from "adds nothing to security" to "theoretical security advantages" ... I guess that's some progress at least.

Here's the thing about theory though: opinions, everybody has them. And what isn't worth it for you is not the definitive answer for everybody.

Can you imagine how an app like Google Docs would function without multiple concurrent requests? Our app is an editor that's very similar and it wouldn't be worth building under those constraints.

See, the same thing again: Different use cases, different considerations, different trade-offs, different solutions.
Just because you don't believe it's worth it for you, doesn't mean that the double-submit cookie mechanism was even the right solution for you in the first place.

Having a user click back and being unable to submit a form provides a bad user experience

Have you heard of the PRG pattern? And applying different solutions to different problems in general?

and security should never trump usability.

Sorry, but this quote alone disqualifies you from talking about security. You don't get it, you don't take it seriously enough.

If it does another approach to security is needed not the other way around.

You're not suggesting another approach, you're telling people to decrease security.