(vector (aref s 0)(aref s 0)) bug

It’s a known bug that (vector (aref s 0)(aref s 0)) is not returned correctly to track. Rather than producing a stereo track with (aref s 0) in each channel, the data (aref s 0) is split into tiny chunks and distributed between the two channels.

I’ve no idea how to debug the source code that lies behind this bug, but it looks like the problem may be that Audacity is getting confused about the start and stop times when there is the same sound element in each vector field.
The Nyquist manual recommends using “extract” or “extract-abs” to specify the start and stop times, and sure enough the following code works as expected:

(setf stereosound (vector (osc 60) (osc 60)))
(multichan-expand #'extract 0 1 stereosound)

or more simply

(cue (vector (osc 60) (osc 60)))

It is enough to write

(osc 60)

Audacity simply copies a from Nyquist returned mono sound to both channels if a stereo track is present.
That’s why ‘(aref s 1)’ copies the right one into both channels.
However, normally this should be done by the code from the topic title - which produces the strange bug.
If I remember right, the size of the scattered chunks is 1020 samples.
This is precisely the amount ‘snd-fetch’ uses in its sample buffer.

(snd-fetch (aref s 0))
(print (multichan-expand #'snd-length s ny:all))

(use the snippet on a stereo track)
Besides, if we return the sound with ‘s’, the returned duration will be the one of the shorter channel.

The problem only occurs when both elements are the same sound.
For example, the following does not have the problem:

(vector (aref s 0)(snd-copy (aref s 0)))

Anything is valid that forces a new evaluation of the sound, such as (mult 1 (aref s 0)) or a similar dummy function.
However, since Audacity duplicates mono sounds, nothing more is needed than ‘(aref s 0)’.
A pity that the reverse isn’t true i.e. that mono tracks are not extended to stereo tracks when stereo is returned (or any number of channels for that matter).