Understanding 'the defaultStack'

[Jeanne A. E. DeVoto]

At 8:40 AM -0400 10/9/2016, Paul Dupuis wrote:
>Your paused script continues executing, but now the defaultStack has
>changed.
>
>As a precaution against users of the app doing (resonable) things like
>this, I now explicitly set the defaultStack after any ask or answer file
>dialog. I also use code such as
>
>on handler
>put the defaultStack into tPreserveDefaultStack
>set the defaultStack to <this stack by name>
>... my code...
>set the defaultStack to tPreserveDefaultStack
>end handler
>
>So that if the hander is called from another stack it does not exit with
>the defaultstack changed.


At this point, I'm starting to wonder whether the defaultStack should 
be redesigned/re-specced to make it more predictable.

I don't think it's feasible to actually make major changes in the way 
the defaultStack works, but possibly a new property could be designed 
that acts in such a way that workarounds like this aren't normally 
needed. Setting and re-setting the defaultStack to make sure it's 
right is almost as annoying as specifying the stack every time you 
refer to an object (which I sometimes do anyway, for fear of the 
defaultStack changing from under me).

If it were being designed from scratch, what would the ideal behavior 
be for a targetStack property? Should it remain unchanged while a 
script is running (unless set explicitly)?