We found the issue. For testing the upgrades in unit tests, we used the original contracts from the original deploy commit and there was a name conflict that must have confused the solidity compiler as it did not use the actual updated storage with the clash variable string foobar.
But the issue that it's not deploying remains:
Attempting upgrade on chainId: 137
@openzeppelin:upgrades:core fetching deployment of implementation 7479059768e7690c632ebd86c2f0f503aff0ab00a1babdd7a378f55baae29d35 +0ms
@openzeppelin:upgrades:core found previous deployment 0x4c49821bf4c5fc7df26988bcb62d15aa645ea0899c04a81e6fc422043b198bc8 +3ms
@openzeppelin:upgrades:core resuming previous deployment 0x4c49821bf4c5fc7df26988bcb62d15aa645ea0899c04a81e6fc422043b198bc8 +181ms
@openzeppelin:upgrades:core polling timeout 60000 polling interval 5000 +1ms
@openzeppelin:upgrades:core verifying deployment tx mined 0x4c49821bf4c5fc7df26988bcb62d15aa645ea0899c04a81e6fc422043b198bc8 +0ms
@openzeppelin:upgrades:core succeeded verifying deployment tx mined 0x4c49821bf4c5fc7df26988bcb62d15aa645ea0899c04a81e6fc422043b198bc8 +163ms
@openzeppelin:upgrades:core verifying code in target address 0x639dFeA994b139A3d6C3750D4C4E24daEc039BD7 +1ms
@openzeppelin:upgrades:core code in target address found 0x639dFeA994b139A3d6C3750D4C4E24daEc039BD7 +185ms
Upgrade considered compatible with existing storage layout.