The technique that came to mind reading the description of the problem was to "remember" the calculated "target" values of the .from() tween when it gets called the first time the component is mounted and then when it gets remounted do a .fromTo() instead (under the hood) using those "remembered" "target" values
Basically that way you're forcing it to tween to the intended target values (instead of getting confused and targeting wherever the first tween had gotten to so far) when it runs again on remount
Here's a rough example that shows encapsulating that behavior in a useDoubleCallableGsapFrom() custom hook: https://github.com/helixbass/gsap-double-call-test (if you clone that repo and then from the top-level directory of the repo run yarn install and then yarn start it should launch the example app locally)
Specifically it's using this technique + gsap.getProperty() to achieve the "remembering"
And caveats: I wouldn't start using this "for real" as-is, there could be fundamental reasons this isn't a good idea, I have no idea if using gsap.getProperty() that way would work for all possible target properties, as written I think you could only use the callback "once" (ie the equivalent of a single gsap.from() call per component instance) nor would it handle if you're targeting multiple elements and they have different calculated "target" values from each other, ...