Caused by 8214109778
Before said commit, a vertexgroup `TreeElement` would take its `idcode`
in a questionable way described in the commit messages of 0c0bc61918
and 0a633a4e07.
Since 8214109778 this is not the case anymore, it is just 0.
4292bb060d made this comment (guess this never happened):
>/* We need to figure out how to deal with the idcode for non-
TSE_SOME_ID types still. Some rely on it... */
So in order to return to the prior behavior, we could just enable the
following line (even for the new type design), this will work, but feels
rather shaky (the basic question here is just "do we want idcode to
point to the owner ID for something like vertexgroups?" -- still cannot
answer this question tbh.):
`te->idcode = GS(owner_id->name);`
So one of the places where the logic relied on `idcode` is alphabetical
sorting. The logic excluded some elements from the sorting (by
explicitly setting their `idcode` to zero) and this is where we now
coughing up because... well we are always having a zero `idcode` for the
new type design.
To resolve, just explicitly enable sorting for `TSE_DEFGROUP` again by
explicitly setting their `idcode` to non-zero(one).
Pull Request: https://projects.blender.org/blender/blender/pulls/130750
531ed68061