This is also possible in principle with the fedimint client, there's more complexity for doing the upgrade because the client associates its notes to the federation id which contains the original endpoints and the guardians have to first agree on the new config then the client has to acknowledge the new config.

99% of the complexity for fedimint here is the consensus not the ecash. But there's (potentially, still confirming implementation options) a short term fix for existing federations to allow a DNS rotation by a guardian and that being acknowledged and reflected in an updated client to reassociate its notes with the new config. Plus a longer term solution to remove the DNS dependency for new federations entirely.

nostr:note1dchlp9hztern24qqk55qy454aakj9wq42wwthxeqjeddrfmgqhaqu92qvm

Neither does fedimint's ecash. The client associates the notes it holds with a federationId and can change that association the same way you do with the mintUrl.

It's more complex for the fedimint guardians to agree on an update to the config, creating the new federationId, but in principal it's the same. the approach to that consensus update process just needs to get agreed on and implemented as part of the next release or potentially a hotfix.