conflict between UNDO and LOCAL

According to the 49g+ AUR, the LOCAL command "is intended mainly for
use in Algebraic mode", but I think I may have come up with a good RPL
use for it. Unfortunately it seems to interfere with the UNDO
command. Perhaps someone can suggest a fix or an alternative.

For example, enter:
1
2
+
UNDO (should now give you back the 1 and 2)

now run a program that has a LOCAL command, such as
\<< { '\<-TMP=1.' } LOCAL DROP \>>

'\<-TMP' RCL (just to confirm that it's there, should give a 1.)
3
4
5
+
UNDO (should give back the 4 and 5, but instead returns stack back to
1 2)

In fact, no matter what the stack is, the UNDO returns it back to 1
2. If I go to the MODE screen and turn LastStack off and then back on
(or go to menu 69.01 and toggle STK off and on), it fixes the UNDO
problem, but destroys the variable. Notice, LastStack is not the same
as LastArg (sysflag 55)

It seems to me that this might be closely related to these two earlier
posts:

Subject: Bug? Using KEYEVAL to toggle last stack corrupts local
variables? (2006)
http://groups.google.com/group/comp.sys.hp48/browse_frm/thread/933eb0e03da78688/ed69d5b5dae18e45?hl=en&lnk=gst&q=LOCAL+UNDO#ed69d5b5dae18e45

Subject: HP49g: UNDO Bug (2000)
http://groups.google.com/group/comp.sys.hp48/browse_frm/thread/36e9fe2dbce692ae/72baddbcd147158c?hl=en&lnk=gst&q=LOCAL+UNDO#72baddbcd147158c


I'm trying to make a variable persistent across runs without using
global variables. I want to run a program such that the first time it
runs, the variable has a particular value, but each successive time
it's run, the value is different.

For example, the first time the following program runs, '<-tmp' will
be set to 1., but each successive time, '<-tmp' is 2.

\<<
@ try to set '\<-TMP' to 2.
IFERR 2. '\<-TMP' STO
THEN
@ if save_last_arg
IF -55. FC?
THEN DROP2
END
@ create local compiled variable
@ and initialize it to 1.
{ '\<-TMP=1.' } LOCAL DROP
END
\<-TMP
\>>

Is there another way to do this without a global variable?
Is there a way to use LOCAL without affecting UNDO?

Thanks,
-wes
.