Don't bother asking web support chat - they will not actually understand the issue and then fob you off by saying it's a your-device problem after taking 40 minutes of my life that I will never get back.
Call forwarding has to be a network-side feature, because it is what configures calls to be sent to voicemail when my phone is turned off or out of signal.
Dialing *#62# (to get the Status of the Unreachable redirect)... Now suddenly worked as expected and showed the redirect to the Voicemail number, now that I've re-enabled wifi calling and all that other stuff that I had switched off for debugging earlier this evening. *#67# (status of Busy redirect) works, *#61# also works (status of No Answer redirect). It can take a good few seconds for the response to show up, and re-testing indicates that it's all flaky - trying some of those again, no response came back at all. Toggle airplane mode on and off and they work again.
But *21*OTHERNUMBER# ("forward all") still fails for me with the same error message - othernumber being a regular UK landline number in zero-first form. As does *#21# to check status of "Forward all".
*002*OTHERNUMBER# (the "All 4" forwarding option, whatever that is) seems to not respond, and neither does *#002# which is "get status of All 4 redirect"). Thankfully, on calling myself from a different phone, I can see that neither the "Forward all" or "All 4" redirections actually went through, so my SMARTY number still rings through to my SIM.
Accessing the Call Forwarding Settings through the Android phone app still gives "Network or SIM card error" - my best guess is that it is trying to query status for the four different types of forwarding (to fill in the information that usually shows "Always forward" to be "Off" and the other three to be the voicemail number) and failing because the request to the network for the Status of "Always forward" is coming back with an error.
I don't feel like trying to change any of the default call forwards that currently go to my SMARTY voicemail to find out if those elements are working beyond can-be-status-queried.
Reviewing everything as kindly as I possibly can: If there's going to be an "engineering at-risk period" for some feature, the helpdesk needs to be informed about it - so they can say "sorry, try that again tomorrow". And if there's an emergent new problem (hey, things go wrong sometimes, I get it), helpdesk need to be able to escalate it. Reaching the the end of a support script and falling back on "idk, must be your phone" is utter clownshoes.
