[Spliff]

Thank you so much again, Kyle, anyway, even if it wasn't so much of work, since the effect of what you have done is spectacular, for us now having a quicksearch - for quick navigation, and for filing - that (optionally) starts at the current entry, instead of (if we didn't want to, or could not, enter rather long, very specific strings) getting us stuck way "above" our intended target item(s); now, with "8" e.g., we can enter "e", for going so "esome", then enter {right}, in order to expand its child items, enter "f", and get to that child item "fsome" -

which before was impossible: navigating to some subtree, and then trying to select something "in there", by quicksearch, threw you back to something way above that intended target, or you had to enter 4, 5 chars instead of just 1 or 2.

Since this "quicksearch" works "depth over breadth":

a (here you are when pressing "e")
b
c (is expanded)
__a
__b
__c
__d
__e (this level-2-item will be selected...)
d
e (...and not this level-1-item),

it's obvious that for general use, 6 is preferable to 5, and 8 to 7, since (for 6 and 8 then), the user has a way of forcing quicksearch to select the target items they really want to navigate to, collapsing vs re-expanding the parent(s), so if we can't toggle between 2 preset settings (but that might be possible with an upgrade?), the even numbers should indeed serve us better than the odd ones, but anyway:

It's correct that if you trigger "Tree - Expand all", while source item is selected, you will load the whole tree into memory, but do that for for a tree with 50,000 items, and you'll see that for big data sets, that's devoid of any interest ; on the other hand, for a tree of 300 items in all, that might be something worthwhile, though, especially if you had put some ("ToDo", or other) "tags" at the start of some of your items, and prefer to work on them directly from tree, instead of from search results.

So for big data sets, I wrote an AHK macro, but which is very simple and thus should be "translatable" to almost any macro tool a user might deploy on their applications, if that tool comes with pausing (necessary) and with looping (not even necessary since instead, the user could just copy the contains of the loop, then paste them e.g. 50 times "in a row", and would be done for any UR db of theirs in which level 1 hasn't got more than 50 entries - and otherwise, we know that when in tree pane, tree being collapsed, ^a will show the needed number in the status bar.

; you trigger this macro when "in UR"
sendevent, ^1 ; go to tree (to be sure you won't create havoc)
sleep, 200 ; (milliseconds)
sendevent, +^t ; or what your shortcut for shift-control-t for Tree - Collapse Tree may be
sleep, 1200
sendevent, {end} ; last tree element
sleep, 200

loop, 45 ; that's a good number for my level-1, and unneeded iterations will just take a little while but won't do any harm
{
sendevent, {right} ; this expands the item if there are child-items, does nothing otherwise
sleep, 200 ; *
sendevent, {up}
sleep, 200
}

sleep, 1000
sendevent, +^t ; or your shortcut: collapse tree again : this takes much less time than to do it 1-by-1 in the loop, and also: have them (i.e. the multiple "level 2") stay expanded for some seconds might "help" UR to successfully load all of them into work-memory:
; *= if you wanted to collapse them 1-by-1 here, with sendevent, {left}, you would have to insert a much longer "sleep" (or "wait" or whatever your macro tools calls that), and with dozens of items, that would add up to some considerable macro running time - and that's why I do it from the last item up to the first one btw

Thank you so much again, Kyle: Even today, UR has become so much more "usable" (it had become so exhausting in the end, having to navigate principally with {up} and {down})!

And I had spoken of (paid) upgrades then, not of updates... ;-)