Since it seems that LAME is one of the better encoders and decoders, and is not patent-encumbered for application use if the end-user installs it, I'd really like to see support for an optional loading and use of LAME if the end-user has installed it, otherwise just return an error, etc. It's a cross-platform way for JUCE to include support for MP3 encoding and decoding without running afoul of the patent restrictions. There would actually not be any MP3 code in JUCE, just support for use of an optionally-installed third-party library...
This is the way I planned to support MP3 decoding and encoding (which I need in my project). It's been postponed due to my core work and other priorities, but that work has ended now and I'm finally renewing my interest in this project. I was hoping that someone else would have already gotten to this, but I will do this work if no one else does before I need it.
Given JUCE's orientation towards audio, I find it very surprising we've come this far without more support for MP3s. Yeah, I know... it's all the stinkin' patent's fault, but I think this end-user installed approach works well. It's the approach that SAM Broadcaster uses to provide optional LAME encoding: http://www.fastserv.com/kb/article/using_lame_acm_codec_with_spacial_audio_sam_broadcaster/
There's a good discussion of using LAME as an alternative encoder in other apps here
And LAME is available for all platforms, so it's got great bang-for-the-buck potential in terms of the benefit of writing a JUCE encoder/decoder wrapper around it.