CSRF and double posting

I only read the title and the first post, which describe the issue as submitting a form twice, which this setting will break if the first request reaches the server.

What are you trying to say here? That csrf_regenerate would "break the issue"? How does that event make sense?

Regardless of what you mean - it's just not true. If it did, the OP would NOT have a problem at all.

It also creates problems with single page apps unless you pass the token back and forth as it changes between requests.

Yes, you do need to update your forms with the new token or use a different CSRF protection method, as you've suggested below.
That's challenging, but that's not a reason to downgrade security.

You can forget about concurrent AJAX requests with this enabled.

No, you can "forget" about asynchronous requests if you're not updating your form tokens.
Concurrency is not asynchronicity; the OP is having the double-submit problem exactly because concurrency is not a problem.

So yes, I do understand how it works, what it's trying to protect against, and why regeneratting it isn't necessary.

No, as explained above - you don't understand it.
All of your arguments are based on doing less work and avoiding hard problems. That is not how security works.

And you're creating these problems for yourself by doing POST requests, which is the only case when tokens are regenerated - on a POST form submission, NOT literally on every request. For the majority of AJAX stuff that you may need to do - anything that doesn't modify server state - GET is the way to go.

Put this at the top of your .htaccess to prevent your site from being loaded into an iframe and have your login page generate the CSRF token.

Code:

Header always append X-Frame-Options SAMEORIGIN

Fair enough, that is a good solution. One that unfortunately didn't exist at the time when CodeIgniter's CSRF protection was designed.
Except, X-Frame-Options relies entirely on the user-agent and you don't need to generate CSRF tokens for it, at all - yet more proof that you don't understand the topic.

Here's a few pages of reasons why this option does not improve security: http://security.stackexchange.com/questi...rm-request

ALL of the referred to reasons are "why this option does not improve security" are usability issues and personal opinions.
ALL of them talk about "each request" and that's where the usability issue comes from. This is not the case here.

And most importantly:

ALL of them talk about CSRF tokens stored in the session. Tokens stored in the session in general don't need regeneration, because the session itself is supposed to be regenerated and short-lived. THIS IS NOT THE CASE HERE!