Okay, so this is essentially in line with the old API talks, in a spun, new way. Bear with me here.
Warning: This post will be highly technical. If you have a poor hand-to-yawn ratio, skip to the bottom.
It stands to fact that we're fairly limited in Second Life when it comes to the core. When we want a shiny new feature, the community needs to sit on their collective hands waiting for the Linden worker bees to magically make it happen.
Of course, it doesn't need to be that way.
So why not let us make our own calls to the graphics and audio system, if the permissions are there? Essentially, make an opt-in system for richer, more open content creation above LL's existing system.
And so I propose:
llOpenGL(list clients, list params) and llOpenAL(list clients, list params)
As defined by library specifications here and here. The key being the ability to rely on standard commands that are easily accessible for advanced applications.
Consider it thusly.
You rez into an open field and find a wooden box labelled "touch me" in floating text. When you touch the object, a permissions dialog asks you if you would like to accept OpenGL and OpenAL calls. You accept.
Suddenly, your client begins downloading the region in streaming, real-time 3D. In reality, the box you just touched is sending your client OpenGL operations directly, requesting new assets to be downloaded in a specific way.
Now you're looking at an entire game world that just rezzed inside of your client's buffer. In the field's place is a giant roller-coaster, held together by meshes and audio signals, all from the asset server and prim you just clicked. Completely new, realistic-looking content has been placed in your viewer, inviting you in.
This is essentially a partial API. The benefits, of course:
- Privacy
Allow calls to be targetted to specific avatars through such a system. If they aren't targetted, they can't see what it is you're doing.
- Scalability
Allow users to encapsulate entire sims in a small system of scripts and notecard-driven meshes (described below). Make Second Life competitive with the rest of the 3D industry.
- Portability
Direct OpenGL/AL calls make the code very portable to and from Second Life. Code would need only to fit in each script or notecard and be in the asset system.
- Richer Content
Allow Second Life to use meshes, already! Give people the ability to store the data in a notecard and call it with OpenGL.
- Standardization
Allows builders to get away from the broken content problem by standardizing the interface. Less of a moving target, more working content.
- Modularity
Highly modifiable at the core levels. Since you're making direct calls to the rendering system, there's no doubt on whether it's you that screw up or the command itself.
- Second Life does most of this already
It uses OpenGL already. Some have even run "OpenGL hooks" to do interesting things with what's already there.
At the end of the day, we should just have an API, but this would be a good start in getting content creators where they should be: Competitive with the rest of the world. For a good example of such an API, read here
Essentially, LL should just let us make calls to the graphics and audio system and share those with others.
And so, I've gotten that off my chest. Good day.
I can imagine how slow that can be on my connection 
