The audio player interface allows playing from a streaming service - e.g. a radio station
This is a continuous stream that could run for many hours - but the skill is only given the opportunity to provide song information at the start.
It could respond to user requests - such as "What song is this?" (which is OK) but, primarily for devices with screens, it would be useful for the skill to be able to provide title/subtitle/graphics as the songs change within the continuous stream.

This could be done by having the Skill start the audio stream with a duration parameter which would result in a callback when it is about to be reached - similar to the PlaybackNearlyFinished request.
The Skill could then send new metadata (potentially with an offset to say display in X seconds) and with a new duration parameter.

An alternative approach that could work without any skill being developed at all ...
If the player automatically took the metadata from an ICY stream (as provided by Shoutcast / Icecast servers) then it would be a good alternative - especially if the skill to parse a regex that should be used to parse the ICY title - with a default that would handle "artist name - song title" which is what many internet radio stations use (and StreamURL for the image).
For example ...
Playing http://www.dandelionradio.com/DandelionRadio.pls.

Name : Dandelion Radio
Genre : Alternative
Website: http://www.dandelionradio.com
Public : yes
Bitrate: 128kbit/s
ICY Info: StreamTitle='Rocker: D. A. Stern - Isn't It Obvious?';StreamUrl='http://www.dandelionradio.com/images/drlogosq-black.jpg';

It's increasingly common and frustrating to have Alexa ignore intents provided by the skill and instead pivot to a native function / keyword function.

For example, in a cooking skill I've included various intents for calling up the list of recipes offered by the skill. But as soon as Alexa hears the word "recipe", she quits the skill and says, "Sure. I can search by dish name and ingredients. What would you like?"

Alexa obviously did not check my list of intents, because if she did she would've read the list of recipes in my skill to the user.

The same problem exists with any intent that includes the word "list". As soon as Alexa hears the word "list" she assumes the user wants to view their Alexa shopping list---even if there are custom intents in the skill to handle user requests with the word "list" in them.

By default Alexa should *always* check for a matching intent within the skill *first*, and only resort to native / keyword functions if she doesn't find a match *within* the skill.

Currently all skills must run through Amazon’s Natural Language Understanding and provide a language model to Alexa. While this is helpful for getting started, many more advanced features for Language Processing and response building benefit heavily from having the user’s speech accessible to perform more complex operations like sentiment analysis, conversation reconstruction or custom natural language processing through models on other services. This allows developers to deliver a richer experience to users through the additional processing it makes possible.
For my use case in specifically it would be acceptable to have an option in the console to disable the language model and only receive the speech transcript in requests, and I think there are other developers who would benefit from this as well. Currently to get access to an approximation of the raw speech requires a basically empty language model, which works but suffers in performance.

Room awareness enhancement: add popular device types such as Fan, Air Conditioner, Set-top-box and let users change device type to their favorite. Now Alexa app allows changing device type between Light and Switch for some smart plug devices. But it would be great if for any device, users can define it as light, fan, air conditioner or set-top-box... and the room awareness feature will help simplify voice command. Users just can say: turn on the air conditioner, turn on the fan...
This device-type-changing feature will be very powerful when an infrared/RF universal remote control like Broadlink is connected to alexa. All traditional “dumb” devices can be voice controlled by alexa taking advantage of the room awareness feature.

The Alexa Skills Kit for Node.js includes support for creating a DynomoDB table to hold attribute values across sessions. To create the table dynamically, the Lambda function is typically given DynamoDBFullAccess permissions.

This feature is to remove the table creation code from ASK SDK Node and move it to the ASK CLI as part of the deploy command. This will allow the lambda function to have reduced permissions to insert rows, read, write, and delete.

Configuration for the table name and region would be stored in '.ask/config'

The command would be:
$ deploy --target dynamoDB

This would create the table if it does not exist and update the role associated with the lambda function to include only the permissions it needs.

Calling 'ask deploy' will also deploy to DynamoDB (if the config includes a table name). Deploy to Dynamo would occur after deploy to lambda so that the function permission could be set.

A public S3 bucket is used to host skill icons, audio files, images, and videos for Alexa skills. This feature adds a new deploy target to the ASK CLI.

Configuration for the bucket name and region would be stored in '.ask/config'
$ deploy --target s3

The would sync all files and folders in a known local folder to the bucket at: https://s3.amazonaws.com/my-bucket/

The first time this is done, the bucket will be created and a CORS configuration applied.

Calling 'ask deploy' will also sync local folders and files to S3. Because the skill icon can be hosted in the S3 bucket, deploy to s3 will occur before the deploy of the skill.json file.

Behind the scenes, the following commands will be called:

# make bucket
aws s3 mb s3://{bucket-name}/ --profile {aws-profile-name}

# set CORS
aws s3api put-bucket-cors --bucket {bucket-name} --cors-configuration file://.deploy-s3/s3-cors.json --profile {aws-profile-name}

File: s3-cors.json
{
"CORSRules": [
{
"AllowedOrigins": ["*"],
"AllowedHeaders": ["Authorization"],
"AllowedMethods": ["GET"],
"MaxAgeSeconds": 3000
}
]
}

# sync s3
aws s3 sync ./.deploy-s3 s3://{bucket-name}/ --profile {aws-profile-name} --grants read=uri=http://acs.amazonaws.com/groups/global/AllUsers

Add ability to add a written command to a routine that would act as if the user spoke a voice command.

E.g.
Routine scheduled at 7:00 AM:
- turn on Light
- tell you something new
(New): - perform “Alexa, what is the weather in Boston?”
(New): - perform “Alexa, open Headspace”
(New): - perform “Alexa, connect bluetooth”

This would enable skills in routines while leveraging the existing abilities of the Echo, just by allowing written commands to be interpreted as voice commands on a schedule. This should be fairly simple to implement with what it is already is capable of, but would immediately and hugely expand the usefulness and value of the device.