If you limit the scope of usage, the old wallet should be garbage collected as soon as you have the new one. If you don't want to rely on that, or the point in time when gc happens is important or you're dealing with sensitive data, then the environment should allow you to perform appropriate cleanup actions and for you to utilize a different means to control and protect the data.

As josephcsible said in a post parallel to yours, affine types can do this for you. If not, though... if you never mess up and keep a reference to the old one, you're good. I don't care when it's garbage collected; if there's no reference to it, it's not going to be used. But if anybody, ever, keeps a reference...

That's actually an argument in favor of linear or affine types. In your example, you'd still get a new Wallet from that function, but the compiler would keep you from accidentally using the old one afterwards. That way, you can't make that mistake, but still get the benefits of immutability.

I will admit that I don't know what "linear types" or "affine types" are. Your answer makes me feel like I am trying to convey an idea for which you have the perfect formalism / meta vocabulary. It might be that objects, or at least the way that I know how to use them in my favorite languges, are just a (potentially limited) implementation of said formalism.

I feel that objects offer a flexibility benefit though (which is why they often elude formal approaches) for the cost of purity.

Rust is probably the most mainstream language that uses affine types. Once you call a function that takes ownership of a value (e.g., `drop`), the compiler won't let you use it anymore after the function call.