Why Does not hiCreateTreeTable support unsort?

OBSERVED BEHAVIOR (identical SKILL code, three releases)

1) IC6.1.7 — sort engine never re-asserts:
- The view mirrors the model order (hiTreeAppendItem / hiTreePrependItem).
- Changing formHandle->field->sort from SKILL has no visible effect.
- hiSetTreeItemDescription() never re-sorts.

: i want this way. this is very cool.

But, After i updated New version, my tools is not working correctly. 

2) ICADVM20.1 — lazy re-sort:
- Re-sort happens ONLY when the ->sort property value actually changes
(e.g. (col nil) -> (col t)). Writing the same value is a no-op.
- Changes made with hiSetTreeItemDescription() do NOT trigger a re-sort.
- Model manipulation (hiTreeRemoveItem/hiTreePrependItem) is overridden by
the last sort assertion.
- When it does re-sort, the sort is unstable: rows with equal keys are
silently reordered (our "divider" column holds the identical string "|"
for every row, so a single sort event visually shuffles the whole table).
- The re-sort is processed by the event loop AFTER the SKILL callback
returns, so any descriptor we restore inside the same callback is lost —
the engine sorts against the already-restored (all-equal) data.

The ICADVM20.1 behavior is particularly problematic: we maintain a dummy
"divider" column solely as a stable sort key (all rows carry "|"), yet any
sort event re-sorts the entire table and silently reorders all rows that
share the same value — destroying the layout we relied on.

3) IC23.1 — live re-sort:
- Every hiSetTreeItemDescription() write that changes the value of the
currently active sort column triggers a full re-sort immediately.
- Ties appear to keep their relative order (not guaranteed anywhere).

At least with IC23.1, the dummy-column approach remains viable: re-sorts
triggered by description writes preserve the relative order of equal keys,
so our "|" divider column keeps the layout intact without any further
tricks.

Our environment requires us to support multiple Virtuoso releases
(IC6.1.7 / ICADVM20.1 / IC23.1 and more ) with a single tool, so we cannot simply
pick the best-behaving version — we have to work around these inconsistent
sort behaviors ourselves. A portable, documented solution is therefore
essential for us, which is why we are requesting this clarification.

We fail to understand why the view re-sorted automatically at all: the edit
changed a non-sort column (GRADE) only — the active sort key column ("|"
divider) was not modified — and no user header click occurred. Under the
documented model, nothing in this operation should trigger a sort.
------------------------------------------------------------------------------------------------------------------------------------

1. Is there a way to prevent the unintended automatic re-sort? Our tools
update cell descriptions for display purposes (grade edits, state marks),
and on some releases this — or the associated ->sort write — causes the
view to re-sort and reshuffle rows, even though no user requested a sort.
Can this automatic re-sort be suppressed or disabled from SKILL (a field
option, an API, or a mode)?

2. For the cases that remain unsolvable even with our dummy "divider"
column approach (specifically ICADVM20.1, where a single legitimate sort
event reorders all rows sharing the same key "|"), would Cadence provide
a hotfix/IPR? A stable tie order — or honoring the declared
compareFunction on the programmatic path — would make our current design
work as intended.

3. Going forward, are there plans to add explicit API-level control of
sorting — e.g. an option to disable automatic/header sorting on a tree
table field, or a documented "re-sort now" API with identical semantics
across all releases (IC and ICADVM)?

4. To be clear about the severity: in our assessment this is a serious
defect in the tree table API contract — it silently corrupts user-facing
display order in production tools and leaves no portable, documented
workaround across supported releases. We strongly request that this be
fixed (behavior alignment or a documented control API), not merely
explained.