Sorting order in Lighttable (small issue, have workaround/fix)

Is there an existing issue for this?

• I checked and did not find my issue in the already reported ones

Describe the bug

The sorting in the lighttable has a feature:
When you sort on a property (filename, capture time, etc) and then on something else, the first one becomes the second sorting key.

This led to rather strange behaviour which I have now fixed.

I was editing photos and moving to the next and the next using and I could not figure out why it sometimes skipped photos.

Steps to reproduce

Go to light table
Sort on modification time
then sort on capture time
Edit a photo that is part of a high speed capture
move to the next photo by pressing

... find that sometimes it has skipped 2 or 3 photos.
Also the sorting order in the lighttable changes.

I want to acknowledge: This is perfectly explicable when you know how it works. This is precisely how it is programmed.
However, from the user experience it is really weird that the sorting order sometimes suddenly changes (it only happens with burst photos). It is working as designed but from the users perspective it looks and feels unpredictable.

If a user never worked out that the previous sorting key becomes the secondary sorting key, they can be stuck with this for decades and never work out why it's strange.

Expected behavior

perhaps always use the filename as second key and capture time as tertiary key. Or never use mod-time as a secondary key when Capture time is the primary key.

Logfile | Screenshot | Screencast

No response

Commit

No response

Where did you obtain darktable from?

darktable.org / GitHub release

darktable version

5.2

What OS are you using?

Linux

What is the version of your OS?

Linux mint

Describe your system

No response

Are you using OpenCL GPU in darktable?

None

If yes, what is the GPU card and driver?

No response

Please provide additional context if applicable. You can attach files too, but might need to rename to .txt or .zip

No response

Start at the light table sorting and next-photo navigation entry points, then reproduce the stated sequence: sort by modification time, sort by capture time, and advance through burst photos with . Confirm the intended secondary-key policy with maintainers; done means the sorting order and next-photo navigation remain predictable under that sequence.