say do loop { state... fix might be hiding the actual problem

[zoffixznet]

Opening this, so we could have a closer look.

RE: #1467

From: https://irclog.perlgeek.de/perl6-dev/2018-02-06#i_15783385

13:35 	jnthn 	That looks correct, though a PR that I think touched that recently 
            had a slightly bothersome description
13:35 	jnthn 	In that the state var shouldn't need to move in this case, and doing 
           so would probably hide a different problem
13:38 	jnthn 	Zoffix: Yeah, didn't have time to dig any further but the movement 
           of it outside of the block it was declared on feels wrong. I think that'd 
           just be hiding the real problem (and probably making a new one)

[jstuder-gh]

So would it be accurate to say that the real issue was that the cloning target was wrong?
Right before the statevar move in the sub, make_thunk_ref is called wrapping the immediate block in a new block. Should the new enclosing block and wrapping never occur at all?

I remember experimenting with a modification to make_thunk_ref that took an arg indicating whether to reuse the same block (changing the block from immediate to declaration_static; arg also defaulted to creating new enclosing block if no value provided) but when running the spectest there were errors on tests involving UNDO phasers. I backed off then, but was that a better path to be taking? Allowing the existing block to be used as the cloning target and figuring out how it is affecting phasers and address that?