[Spliff]

Because, when a %CHANGED% (or similar) is 1/true, I'd do exactly that, AND I'd have to insert a (hopefully sufficient) "wait" in the macro (some 1500ms), before the next "real" command, whilst I (have to) retrieve the "command-line" anyway, its processing (= analysis of the retrieved string) then being immediate, an NO need for the (otherwise mandatory) "save" "wait" if the sysvar is 0/false. In other words, "save" is among the multiple commands where my AutoHotkey macros have to "wait" for, in order to not to "choke", whilst e.g., the programmatic creation of multiple new files, or multiple file renames and even moves, from within AHK, doesn't pose a problem; the creation of a new UR item (even while it's empty yet) HAS to be waited for by AHK, before further processing.

Ditto for %EXPANDED% (or similar): (Even unnecessary) "expanding" will cost time, while, if I don't allow for that time, the macros "choke". (It goes without saying that any ancestor of the current item, to be retrieved from the TitlePath of th current item, IS already expanded, so no "check" for a sysvar is needed for them, but the same is not also true for "lateral" paths, from the first child item below the bifurcation of the two paths down.

(What's missing, on my = the AHK side, is the availability of some system info, "system is busy" or the like, which could check IF a save is currently done, and "wait" only then. Btw, similar problems, in AHK, arise (and are discussed within the its forum) when a macro tries to retrieve quick changes of the the current window's caption: It systematically retrieves the previous values then, not the current one, so retrieval by other means (in UR: the "command line" sysvar) is both quicker AND much more reliable, even when it implies clipboard use, which in itself isn't that "reliable" to begin with - but as said, the UR "command line" is retrieved quite fast indeed, thankfully.)


EDIT:

This arises the question if I should switch to CharSearchMode 7, instead of 8, which would eliminate the "is_expanded_or_not" problem, and make those scripts (navigation = "go to" some item; move some item to ...) much simpler, and much quicker indeed; the problem being that currently, this is not a toggle, but a registry entry, changes upon which come into effect from the next UR run only.

When you introduced these additional CharSearchModes, I had briefly trialed #7 (since it had been my idea), but I then quite fast changed to #8, since in regular, day-on-day-off use, #7 had produced too many unwanted "hits":

item 1
item 2 (collapsed, but with children aitem, bitem, citem, sitem)
some other item

I'm on item 1, I enter "s", I want to go to "some other item", but #7 opens up sitem, within the sub-tree below item 2, no in "normal day" use, #7 is scarcely useful.

On the other hand, for my navigational, and move scriptlets, it'd be pure gold, since they, within a fixed naming structure (sic!), are meant to do exactly that: go to, or move to, precise, and even collapsed-out (their respective parents are collapsed, they themselves are thus collapsed-out, thus my "weird" wording here) target items: #7 would make this neat and fast.

Thus, a possible toggle, between TWO preferred CharSearchModes, one being the default (#8 in my case) and a special one (#7 for my scriptlets) would make those much more elegant, much less cumbersome indeed, but without constantly interfering in day-to-day character search, the one the user uses when they simply want to jump from one sibling to another one, within the immediate vicinity of = below the first one.

Unfortunately though, I think such a toggle will NOT be possible, since it (allegedly) affects the internal processing of the tree component (similar, btw, for the setting "wordwrap in tree" which would be individual for each db, instead of remaining the current setting for all DBs (which makes it more or less unusable since for most "things", the user allegedly wouldn't want it to be that way, just for some specific data).

As said before, with #7, my macros would become really elegant, which they currently (using #8) are not - all those "waits" in-between are really quite awful, for the "user experience" -, so I'm even considering to switch to #7 indeed (being ready to navigate "manually" from one item, to some sibling of it, just 5 or 8 positions further down... since, at the end of the day, that's what I need to do anyway, every time that sibling is 5 or 8 positions above the current one) if you can't make it a toggle between CharSearchMode1 (#8 for most users, I suppose), and CharSearchMode2 (secondary, to be switched on just for specific macros).