Er, no - or at least we can't say it won't do that without much more info.
The previous version didn't in fact trim "over and over again" unless it was "reset" - and then the next trim is for a new event, because it's been reset (if a system has no memory of previous state due to a reset, anything is a new event). If the pilots had known that "all" they had to do was hold the column against one MCAS-cycle of trim and not reset it (not touch the trim), MCAS might not have been as lethal.
Thing is, there has to be a reset, there has to be an end-of-event (even if it's WOW or end-of-flight), and after reset MCAS can trim again. I think I understand why the original reset was done the way it was, working from what has been revealed about the way MCAS was implemented I've tried to put together plausible implementation logic / pseudocode, and if you reset it the way they did (going from published info) you end up with something that is very definitely in the "simple, elegant and wrong" class of solutions. Really simple, really neat, deceptively enticing. I can even see how the post-flight-test changes that made it more lethal may have eluded some reviews, because they could have been done with no actual code changes at all (no logic, just values of constants - data initialization).
What I can't see is how you "fix" the reset problem without introducing a lot more state into the logic, way more aircraft-state inputs, way more complex calculations, and probably orders of magnitude more lines of code. Even then, somewhere, somewhen,there still needs to be a reset, and hiding behind that implementation is the risk of MCAS trimming over and over again. Now I haven't done real time control stuff for decades, nor flying code, there may be a solution that is simple and elegant and right, they may even have found it... but I have a suspicion (especially given the reported problems with it) that MCAS is now a solution that is complex, ugly, and maybe right - but very hard to prove it isn't wrong in some circumstances.