I don't think this technically classifies as a bug (as it is technically correct), but I'd love to see more input on whether this should be changed to reflect your desired behavior. Tentatively, I do agree that this should be changed, but I haven't thought much about it.

One way to think about it is that directories have an implicit .dir extension and thus any other . in the directory name should be ignored.

I've found the current behavior surprising. For instance, when listing the installed packages on NixOS, I'd expect the multiple eza versions to be listed together. However, the *-eza-0.17.3 and *-eza-0.18.0 directories are sorted with other packages based on .3 and .0, which is not what I want. On the other hand, all files sorted by their extensions is what I want.

Given xkcd 1172, maybe eza can offer a new --sort=fileextension (or equivalent) option?

I do think the current behavior is a bug, but would be happy to be corrected as to why it is useful or expected.

One way to think about it is that directories have an implicit .dir extension and thus any other . in the directory name should be ignored.

I find this is pretty horrifying way of thinking about it, ngl. =P

Shouldn't be a very tricky patch tbh, putting aside bikeshedding over how it should be handled.

This is how it behaves if the sorting code just short circuits out to 'equal' if either the A or B input is a directory when it is asked to sort by extension.

Crude fork that fixes this.

I am wishing this will be considered more seriously in the near term. Just listed a directory containing subdirectories with names like 01. people, 02. cities, etc and eza --group-directories-first --color=auto --sort=extension sorted 02 before 01.

IMO, using --sort=extension should probably imply --group-directories-first and directories should be sorted by names only.

Alternative is to think of directories as containing an implicit .directory extension and be sorted according (e.g., all directories are sorted to be after file.csv and before ventoy.exe). Not horrible I'd say, but opinions can clearly differ as above.

@cafkafk will you accept a patch for either of these solutions?

Thinking more on this, the simplest solution is to treat all directories exactly as if no . is present in the name (i.e., None extension) when sorting.

This was bothering me enough to implement a fix. Thanks @Omnikron13 for showing how to do this.