I now have a better description of the issue.  Create a new file with the default account trees for investments, retirement accounts and spouse retirement accounts.  Assign 5 digit account numbers only to the lowest level accounts in such a manner that the numbers for each lowest level investment type have the same second or third digit.  This assures that the strict ascending or descending numerical sequence would cross all three second level sub-accounts.  

Now clicking on the account number title will sort the lowest level sub-accounts within each upper level account, but it will not sort across higher level accounts to achieve a perfect numerical sort.

If the account number column is dragged to the left edge, the triangle symbols that denote the sub-account levels remain on the left in the account number column instead of staying with the account type/description column even though they are more strictly defining the hierarchy by account type and description sub-level rather than by numerical sequence.

The result is that it is still impossible to sort strictly by account number.
Another way to state this is that the account number cannot be made the primary sort key.

I believe that the first account number digit can work to sort types numerically if, for example, the user wishes to put income accounts before expense accounts, so the rules are not completely honoring level above numbers.  I would have expected a numerical account sort to override middle level sub accounts at least for display purposes even if the tree structure is retained logically for some purposes. 

In register windows the date is the primary key but it is possible to sort strictly by other fields even when the only rationale is to occasionally assist alternative searches for certain details.

If that is the correct behavior I think that should be clearly explained in the manual.

The underlying control is a GtkTreeView, which hard-codes displaying the accounts hierarchically. Attempting to sort to an account numbering system that doesn't match the account hierarchy is therefore guaranteed to break. The only way to make it work would be to switch to GtkListView, but that would require that the name sort used the fully-qualified names (e.g. Accounts:Current:Checking) to maintain the hierarchical name sort and there would be no expanding/collapsing. We're not going to do that.

So what documentation would you like to see and where would you like to see it?

Since the help documentation is currently under review, I will limit my suggestion to mentioning somewhere that if an account numbering scheme is implemented by the user it will break if it does not match the same hierarchy that is defined by the hard coded account structure.  I guess that should be with the help for account numbering, wherever that ends up.  

The help should spell out what are the specific structural details that need to be matched.  Are hyphens or periods allowed, for example.  Do alpha characters need to meet certain restrictions?  Are there restrictions that vary in certain languages?  Some of that is already covered in the existing documentation.

I vaguely recall that the auto re-numbering assistant aka Druid may not follow the same rules religiously.  If true, that may require separate handling.

As for the more general notion of messing with the title bar to accomplish column order and custom sorts, the help for that activity should include a reference to the section about designing account number schemes.  Which windows allow sorting by that method?

Those are my current thoughts.

Following up on the conversation I have reassigned this bug to the documentation category.

GnuCash bug tracking has moved to a new Bugzilla host. The new URL for this bug is https://bugs.gnucash.org/show_bug.cgi?id=747333. Please continue processing the bug there and please update any external references or bookmarks.