Has there been any movement on this, as I note that the original idea was Apr-2019 ? It would be extremely useful to be able to securely share the audio files with a limited set of users, rather than needing to use pre-signed URLs which open the S3 bucket upyo any user (with access to that link, for a limited time period).

Absolutely!
Would be great to add the ability to add custom headers to the AudioPlayer directive. At the moment it supports only static url. If you want to get audio from the resources protected with the oauth2, you must pass the access_token in the HTTP header: Authorization: Bearer oauth2-token
At the moment it is not possible because the AudioPlayer directive doesn't support that:

{
"type": "AudioPlayer.Play",
"playBehavior": "valid playBehavior value such as ENQUEUE",
"audioItem": {
"stream": {
"url": "https://cdn.example.com/url-of-the-stream-to-play",
"token": "opaque token representing this stream",
"expectedPreviousToken": "opaque token representing the previous stream",
"offsetInMilliseconds": 0,
...
}
},

It would not be difficult. The media player isn't actually a component of the AVS Device SDK. The SDK comes with a wrapper for Gstreamer and Android Media Player:
https://github.com/alexa/avs-device-sdk/tree/master/MediaPlayer
This media player already uses the HTTP get requests to get audio streams from the web. So, it would not be difficult to implement support custom HTTP headers. For example:

{
"type": "AudioPlayer.Play",
"playBehavior": "valid playBehavior value such as ENQUEUE",
"audioItem": {
"stream": {
"url": "https://cdn.example.com/url-of-the-stream-to-play",
"headers": [{"key1":"value1"}, {"kay2":"value2"}, ...]
"token": "opaque token representing this stream",
"expectedPreviousToken": "opaque token representing the previous stream",
"offsetInMilliseconds": 0,
...
}
},

extremely useful feature this one would be

We have also seen this need for several of our clients that provide premium content in their Alexa skill. For companies whose intellectual property is the audio content themselves, it is important to be able to protect that content and only serve it for authenticated users. Having it simply on a public (albeit possibly obsure) URL is not a sufficient solve, and using something like one-time use links with limited expiration dates still aren't 100% a replacement for being able to simply authenticate each request.

(for account linked skills) One suggestion would be to request the audio url with the same access token that would be passed to the skill endpoint.