Setting to NEW as A. Kemp reproduced in the AskLibO page.

Reproduced in:

Version: 7.2.0.0.alpha1+ / LibreOffice Community
Build ID: bb54d6d8241a06a6772052b77b67d6a4f686426c
CPU threads: 8; OS: Linux 4.15; UI render: default; VCL: gtk3
Locale: en-AU (en_AU.UTF-8); UI: en-US
TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2021-06-11_20:14:38
Calc: threaded

There is a bug here, but it's not what the OP thinks it is.
The bug is: autofilter overwrites the sort range's descriptor.

The OP wants the natural sort order, but that's not available through autofilter. So we sort the range with options and then add Autofilter. The problem is that Autofilter, when actually applied, overwrites the sort order option set in the sort range's descriptor.

1) Open a new Calc document and enter the OP's data into a column of cells along with a heading row of "data", but we scramble the data a bit to confirm that the sort is happening.
Our cell contents are:
data
aaa2004
aaa_2006
aaa_2005

2) Select the range including the heading and sort it with options:
2a) Select the range including the title
2b) Choose Data menu > Sort...
2c) Choose Sort dialog Options tab
2d) Check "Range includes column labels"
2e) Check "Enable natural sort"
2f) Click OK

The data is now sorted as the OP wants. Our cell contents are:
data
aaa2004
aaa_2005
aaa_2006

3) With the range still selected, choose Data menu > Autofilter
Autofilter sees that the range has a column heading set by the sort range's descriptor and does not ask whether to use the first row as a heading. This is good. The range's heading cell now acquires the Autofilter dropdown menu button, but nothing will happen to the data until the Autofilter option is exercised, which we will do in step 5.

4) With the range still selected, confirm that sort options are still set.
2a) Choose Data menu > Sort...
2b) Choose Sort dialog Options tab
2c) See that the column labels and natural sort options are still checked
2d) Click Cancel

5) Sort the range using the Autofilter's dropdown menu button in the heading.
5a) Click the downward pointing triangle in the heading cell
5b) Click Sort Ascending

Notice that the data is now sorted as the OP's complains, not the natural order.

6) With the heading row still selected, verify sort options once again.
6a) Choose Data menu > Sort...
6b) Choose Sort dialog Options tab
6c) See that the column label is still checked but the natural sort is now unchecked.
2d) Click Cancel

Step 6 shows that the Autofilter sorting action overwrites the sort descriptor. The Sort Ascending and Sort Descending UI buttons and corresponding menu options are even more egregious, wiping out the entire sort descriptor including the column heading. Is this by design? I think not.

As far as the default sort order, I find no fault in LO Calc's choice.

Unicode Technical Standard #10 UNICODE COLLATION ALGORITHM
https://www.unicode.org/reports/tr10/

declares as the basic principle:

"The position of characters in the Unicode code charts does not specify their sort order."

The meaning of "Unicode order" is thus utterly ambiguous because code points collate in different orders for different languages. However, taking the cue of "unix ls" as the OP's desired sort order, the "Enable natural sort" option should be selected by the OP. The default sort order used by LO is in fact the start of the Unicode code set, where the first 127 characters copies the 7-bit ASCII code: punctuation precedes digits which precedes alphabetic characters.

Dear PBrockmann,

To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.

There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.

If you have time, please do the following:

Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/

If the bug is present, please leave a comment that includes the information from Help - About LibreOffice.
 
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice.

Please DO NOT

Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not 
appropriate in this case)


If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/

2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to 'inherited from OOo';
4b. If the bug was not present in 3.3 - add 'regression' to keyword


Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa

Thank you for helping us make LibreOffice even better for everyone!

Warm Regards,
QA Team

MassPing-UntouchedBug