- Maybe make the new S_FORM_TOKEN_LOGIN template change "implemented, but not actually required yet." i.e. Unlike normal uses of check_form_token(), make the login_box() usage only validate the FORM_TOKEN "if those fields actually exist in the form." And don't make the S_FORM_TOKEN_LOGIN change strictly required by login_box() until 3.2.7 or later, after there has been time for style authors to consume the 3.2.6 changes.
- The argument could probably also be made that if we're going to neuter the check_form_token() like that during login_box(), the check_form_token() call could just be completely commented out for now, and make it "not required" even for a compatible 3.2.6 style. And simply wait until 3.2.7 or later to finally un-comment the check_form_token() usage in login_box(), after there has been time for style authors to consume the 3.2.6 changes that were "present but not being used yet."
- Make the new S_FORM_TOKEN_LOGIN template change in 3.2.6, but then have the login forms inject the FORM_TOKEN fields by overloading the existing S_LOGIN_REDIRECT variable that phpBB styles already implement. i.e. Instead of only the redirect form field getting injected through the S_LOGIN_REDIRECT variable, "temporarily" both the redirect form field and the FORM_TOKEN fields would come in through that variable. And don't start actually sending the FORM_TOKEN fields through the new the S_FORM_TOKEN_LOGIN variable until 3.2.7 or later, after there has been time for style authors to consume the 3.2.6 changes.
- Make presentation of the login_body page test whether S_FORM_TOKEN_LOGIN is referenced in the template about to be used. Force proSilver if its absent. Still leaves all other usages of login_box() broken in a non-compatible style, but at least "login to the board to investigate and fix the issue" isn't 100% broken.
EDIT: Since the original issue fixed in 3.2.6 is flagged as a security issue, I'll assume the default position here is "we must make the new form token fields mandatory in this release." In which case I like option #3 the best, in which the security fix is delivered even to non-3.2.6-compatible styles "against their will", and without their knowing that they've been "tricked" into including additional hidden form fields.
And then later, in phpBB 3.2.8 or 3.3.1 or whatever, phpBB finally starts delivering the fields through S_FORM_TOKEN_LOGIN as intended instead of through S_LOGIN_REDIRECT, after the styles have had a chance to catch up. Which won't prevent issues from still happening when it's made mandatory later, but hopefully the set of affected "can't login" users is much less than what it is right now trying to make it mandatory in 3.2.6.