This is true, but it’s rather a feature request than a bug. Remember that container items appear as a single item to the user and also to the other internal components of mAirList. The player does not know that it is actually a sequence of items.
Here’s some technical background for those interested in the internal architecture of mAirList:
Each IPlaylistItem (except for those which are not playable like dummy items) has a method BuildSource. You pass information about the audio device to use (given as an IAudioDevice interface) and receive an IAudioSource interface. The IAudioSource interface can then be used to start and stop playback of that item on that device, for seeking, setting the volume etc. Take a look at the CHM file for the various methods of IAudioSource.
When loading an item into a player, the player creates two IAudioSource: one for ordinary playback (using the playback device) and one for PFL (using the PFL device).
For single files and BASS.DLL playback, the object returned by BuildSource is really simple, because it just passes the requested actions (start, stop, seek, …) to BASS.DLL using the corresponding calls from the BASS API.
For containers, the audio source object is much more complex: It creates a separate IAudioSource for each item from the internal playlist (using BuildSource again), and starts and stops them as needed as you call its IAudioSource methods. For example, when seeking to a specific position, it needs to determine which of the items is the “current” one at that point, seek and start it and stop any other.
However, both objects implement the very same IAudioSource interface. The player does only use this interface to start and stop playback, and he cannot tell one from the other. In fact, he does not care.
IAudioSource has the opportunity to offer a “dynamic title”, retrieved by the GetDynamicTitle method. This feature is used by the stream and container audio source objects in order to display the title of the current song in the player. Presently, this is the only way for the player to “look into” the source and identify some “internal sub-structure”.
In order to implement logging for the individual sub-items from the container, the IAudioSource object needed a way to advise the player that playback of a different internal item has begun. This is not difficult, but it requires a little work.
PS: Cad, I just noticed that you posted this in the Feature Request forum. Well done!