It’s worse. You will have the same timer code running at the same time. This means with the new one changes variables those changes will be made to the old one too. That’s the problem with lambdas in general. They are not thread safe and unless you create a new one, multiple threads will be working with the same code instead of their own copy of the code.
Usually we never notice this sort of problem with Timer lambdas or forEach and the like because we tend to intuitively avoid the use case you brought up (e.g. reschedule before the Timer is finished). We more often see this problem with global lambdas because it’s much easier to have two Rules execute close enough together that a given lambda will be called before the previous call finished.
@Karol, rossko57 is doing a great job helping here. I’ve only one alternative idea.
I have a philosophy when working with OH that sometimes it can be easier to solve an error by changing the overall approach so that the error isn’t even possible. In this case, perhaps we can solve the problem, or at least get more useful and meaningful errors, if you instead used the Expire binding instead of Timers. See Design Pattern: Expire Binding Based Timers for details.
This would move the errors out of the lambdas which can be informative. And sometimes just reworking the code reveals the problem as you refactor things around.