As far as I can see, M3U playlists are supported through the audio/x-mpegurl 
mimetype (in shared-mime-info-0.16). Maybe some aliases are missing.

However, I think more important is that <sub-class-of type="text/plain"/> is 
missing. Because of that, Nautilus doesn't want to associate audio/x-mpegurl 
mimetype to .m3u files that do not contain the #EXTM3U string (Ubuntu 5.10 
Breezy).

Another detail, "MP3 audio (stream)" is not properly describing .m3u files, 
because they may also be playlists, not only streaming. Why not just "M3U 
playlist"?

About Nautilus bug:

Try opening any text file with an .m3u extension in GNOME. The #EXTM3U string is 
not required, and as far as I know, M3U files are always plain text.

Could you please point to a server that would be using "audio/m3u" as a
mime-type, in the wild?

Bugzilla Upgrade Mass Bug Change

NEEDSINFO state was removed in Bugzilla 3.x, reopening any bugs previously listed as NEEDSINFO.

  - benjsc
    fd.o Wrangler

(In reply to comment #2)
> The #EXTM3U string is not required,

Seems to be true for the simple playlist. But there is IMHO no chance to detect simple playlists with a pattern. I guess the global pattern .m3u will catch them perfectly. But the #EXTM3U string is mandatory for the extended playlist format.

> and as far as I know, M3U files are always plain text.

True. But the database already defines .m3u to be a sub-class of text/plain.

(In reply to comment #3)
> Could you please point to a server that would be using "audio/m3u" as a
> mime-type, in the wild?

Even two years after the request I cannot find any reference nor an RfC.

IMO this report can be closed.