Can you add another variable "itemchanged" to the item's "command line"?

[Spliff]

Before navigating off from the current item, or before copying / moving it, UR automatically SAVES the current item IF its content ("Item Details", "Item Notes") has been changed in any way (and if a periodic or manual (user-triggered) change hasn't occurred in-between that is). (This doesn't also apply to possible item title changes which are processed immediately.)

This automatic save "at leaving the item" takes some milliseconds, from just some to multiple ones; now my macros, both for navigation away to another, specific item, and for moving an item to another, specific location, first retrieve the current item's "command line" anyway, and that, albeit implicating the clipboard, works very fast, so this systematic command line retrieval doesn't "cost" too much.

On the other hand, and since the possible duration of a necessary "save" can't be determined "from the outside", i.e. by a user macro, the necessary "wait" for that "save" to proceed should not be too short, perhaps 1,500ms (which will cover most of such "saves" at least), and that IS a cost indeed: unavoidable IF there will be a save, but totally unnecessary if there will be no save in-between.

That's why, before sharing my macros, I would like to amend them a little bit in this respect, i.e. make them avoid that "wait" when there is no need for it.

That's why I would like them to retrieve some sysvar "the current item has been changed AND will need a save upon leaving it", short "item_is_changed" 1 (default = 0) or similar, inserting such an extended "wait" just if necessary, not systematically anymore.

(I don't know of course if this is technically possible, since I just suppose (sic!) that UR changes (from false/0 to true/1) some, already existent, sysvar "ItemHasBeenChanged" after any input, in order to then trigger the periodic save when it's time, and also, to trigger the save on leaving the item, but it's also possible that both saves are triggered anyway but do nothing if there has been no change in-between, in which case such a var might not already be present?)


EDIT:

I don't know how I could forget, since another sysvar, %ItemExpanded%, is even much more important in this context, since whilst some %ItemChanged" would be retrieved just once per macro, at its starting point, %ItemExpanded% would even to be retrieved several times, in order to avoid "waits" within the macros, or then to avoid wrongdoings - when the macro is "stuck" at some point / item, for insufficient "wait", then, for navigational purposes, it will just navigate to a non-intended target item, but if the same occurs within a "move" macro, the item to be moved will be moved to some non-intended position within the tree, which is even much more annoying, and in fact, it had been these malfunctions vs. unnecessary "waits", slowing down the macros too much for being "presentable" (when a macro takes as long as manual navigation would have taken, it becomes devoid of interest after all), which made me hesitate some weeks ago. (The pretty thing in this context being that if some higher-up parent item is not yet expanded, we know, without further check(s), that the deeper-down, intermediate targets are not expanded yet either.)

(Btw, your brilliant "expand by n level" commands have been very helpful here, too, already (in fact, the "expand by 1 level" variety), in view of the fact that the commands I had used originally, {backspace} and {right}, both work differently (sic!) upon an item, depending of it being expanded or not, making macros using those commands totally unpredictable and thus unreliable: These problems are resolved now, with "expand by 1 level" (instead of {right}, and by "go first sibling" (which had been available previously; by Alt-{home on my system}), and then "go 1 up" (just {up}), instead of {backspace}.)