It's perfectly possible to use the Synchroniser Token pattern together with proper navigational/multi-tab support. It's only if you take the questionable advice:
To further enhance the security of this proposed design, consider randomizing the CSRF token parameter name and or value for each request
that you have problems. In reality there is no good reason to do this on every request.
There is only a benefit to cycling the CSRF token at the point where a session elevates authorisation - typically on login and other paths that changes logged-in state (eg registration, account recovery, switch-user). These are the points at which you should also be cycling your session identifier, so it makes sense to do both at once. Changing the session ID prevents session hijacking through session fixation; changing the CSRF token prevents a CSRF attack through session fixation.
Navigation back to a cached page in the logged-out or previous-login state (or holding one open in another tab) and then trying to do something will indeed break, but most people probably won't be expecting that to work at that point.
httponly, as appropriate.) Then if it doesn't match you can add a warning div and reload link to the page, and/or prevent active form controls on the page from being responsive. You'd run that check
onpageview for bfcache if you're allowing caching, and potentially on an occasional poller to catch the multi-tab case. (This can also be of use to catch session timeout on the client side and present a friendlier error.)