Thanks. I think with the current list implementation we cannot handle this use case.
Imagine you would have a 100k items in your list and you would select the last item.
It would mean that we have to show the whole list, but this is precisely the point
of the paging. The same mechanism is actually used also when you write a selection
query for a group, so having 100k items is not an unusual case.

I agree that it is not intuitive, but handling it will require a new implementation
of the list. For example, we can imagine having some sort of ... in the middle of the
list and show only the selected items (in your case it would be (1,2,3,4,5,6,7,8,9,10
... 14) . We will likely get to it but not in the near future, unfortunately.

Or do you have another idea?

As per my understanding, PaginatedMorphTreeMorph can have two modes of expansion: incremental
mode or scroll to the page of selected element(s). 
Incremental mode expands the list up to the selected item. Paged mode shows a fixed
number of elements on each page and jump to a specific page item selected. To see it
working, execute script below:

| treeMorph aWindow aModel |
    aModel := PaginatedMorphTreeModel new rootItems: (1 to: 100) asArray.
    aWindow := aModel theme newWindowIn: World for: aModel title: 'test'.
    treeMorph := aModel defaultTreeMorph.
    treeMorph pageSize: 30.

    treeMorph buildContents.
    aWindow addMorph: treeMorph fullFrame: (LayoutFrame fractions: (0 @ 0 corner: 1 @
1) offsets: (0 @ 0 corner: 0 @ 0)).
    aWindow open.
    aModel expandItemPath: {50}.

Glamour chooses the incremental mode and effectively this mode is not adapted for 100K
items. In my opinion, we should use paged mode and it should not require drastic changes
to the current tree model in Glamour.

As for the  bug, the solution will be that the model needs to do expandItemPath: when
a selection is made and update list. And I should provide a fix once we find an agreement
on the selection display mode.

So, here is a proposal for paged list in Glamour. The changes are not drastic. You can
try it with this script. MorphNodeTreeMorph was changed to adapt the position of children.
It is not a bug itself because original MorhTreeMorph does not allow to create children
but since subclasses do, it has to provide  this service, IMO.

browser := GLMTabulator new.
browser column: #one; column: #two.
browser transmit to: #one; andShow: [:a | 
    a tree children: [:one :two :level | level <2 ifTrue: [{level}]]; showOnly: 10; display:
[:number | (2 to: number)]  ].
browser transmit to: #two; from: #one; andShow: [:a | 
    a roassal2
        initializeView: [ RTMondrianViewBuilder new ];
        painting: [:view :number  | 
        view interaction when: TRMouseDoubleClick do: [:ann | ((browser paneNamed: #one)
port:#selection) value: ann element model ].
        view shape label.
                view nodes: (1 to: number + 5).
                view edgesFrom: [:each | each // 2 ].
                view treeLayout  ]].
browser openOn: 100.
((browser paneNamed: #one) port: #selection) value: 15


Let me know what do you think.

The problem with this is that it introduces paging and I specifically do not want that
:(

In my opinion, paging is more adapted for long lists.

-> you don't have to scroll to the 50kth element at the end to see your selection.
-> page size can be modified by the user.
-> I ve seen ppl thinking that a list is incomplete but they only know that they are
looking at a partial view when they reach at the bottom when scroll arrows appear...