Well no, it's working as expected. You just don't understand the use case.
Yes this is known. However for sequential streaming of data then processing blocks out of order isn't desirable, hence the need to alter the interleave. The underlying code only uses that point to decide the interleave. It's easiest to tweak that with the command rather than the command channel.
However it's better to optimise the layout.
It makes pefect sense. After sending the data to the C64, the drive is asked to get the next block, if the disk, due to it rotating, is in the wrong position then it needs to wait for the disk to rotate around before it can read the correct block. Changing the interleave means the drive is more often in the correct spot so the drive needs to wait less time for block to be processed. Try the link again, it's public...
Of course the loader is doing it right, it takes advantage of the drive being able to read and process the data quicker coming from the disk. It's a simple single function call and setting a single override variable, which you can see in the code diff linked above. It's not hard at all...
C1541 is really meant to be a "complete stand-alone disk image maintenance utility", from its own docs. The code change is very small, no large hacks needed either. It also handles tape files, that's "in scope"... Anyway, altering the interleave, which it already does for drive type, is part of drive disk image maintenance. The loader does load out of order sectors perfectly well, it's just faster to read sectors in with a different interleave.
C1541 is really meant to be a "complete stand-alone disk image maintenance utility", from its own docs. The code change is very small, no large hacks needed either. It also handles tape files... Anyway, altering the interleave, which it already does for drive type, part of drive disk image maintainance. The loader does load out of order sectors perfectly well, it's just faster to read sectors in with a different interleave.
For comparison reference: test.d64 uses interleave 10 test2.d64 uses interleave 1 Visually, using interleave 1 means the screen shows multi-coloured bars a lot more often indicating it is doing data transfer and displays a black screen, indicating sector seek/decode, a lot less.
For comparison reference: test.d64 uses interleave 10 test2.d64 uses interleave 1
C1541 interleave command
Cool. There is a rare chance that "cyclic reference found to" will break out so track might be >0, but in that case it really doesn't matter what the final print is, it's going to be wrong anyway.
C1541 chain command no last sector length