That change may work for your case, but I think it may break individually-controlled Tweens. TWEEN.now() is merely supposed to be an API in place of performance.now() in case some browser doesn't have that.

If interested to make a PR but adding this feature behind an API more like TWEEN.lastTime() or similar, and update the tests, that would be great!

Do you have a code snippet that demonstrates what issue you had?

I don't have a code snippet, but here is how you can recreate it:

1. Set up a RAF that calls TWEEN.update(Date.now() + 2500). This sets up the internal clock so that it will not line up with the browser's clock. In my case, I'm using threejs's clock, which tracks in seconds instead of ms.
2. Set up an animation that will take 5 seconds to complete. Do not pass any arguments to start().
3. Observe that it does not behave as intended. I believe in this case, it will start halfway done, because it "started" at the current time, but the update was called with the current time + 2.5 seconds.

You've provided control of the internal clock, but you don't use the custom clock values when you start a tween, so they start in a different timeframe than the updates.

Interesting, haven't used it like that before. Normally what I do is control every tween individually, which may be a workaround for now:

const tween = new Tween(...)....start(startTime)
// ...
tween.update(newTime)

That way each tween can operate with its own custom time being passed in (plus easier to encapsulate the tween to a particular component of your UI, pause it individually, update it individually, etc, while other tweens in other components can also do their own thing).