Well, I really like VirtuaLight, and I'm very comfortable with the VIB- and VS languages. Currently I'm coding a shader editor for VS in Java. But I'm not too hot on C-programming though - I've done it before, but it was a long time ago, so most of my skills in that area are pretty useless...

But I picture this: In the render buttons, a drop-down box in which I can select between the Blender default renderer, the unified renderer, LightFlow or VirtuaLight (and more soon enough). Make the selection, press F12 and voila! For LF and VL-renders the code would handle converting the internal Blender scene data and pass it to LightFlow or VirtuaLight. Unfortunately we would have to build some modules to provide the proper material editing from within Blender as well. And some option to add special attributes to lightsources etc, since there are more things to consider on top of the standard Blender settings.

And some module for setting up render specific global settings, such as irradiance, caustics and more.

What we REALLY need is a general purpose plug-in architecture that could allow anyone to code support for any external renderer. Something like the 'render effects' in 3DSMAX, which allow passing data in an orderly fashion to any app capable of handling some form of image rendering. Sooner or later someone will want to convert their anim to .swf as well...

I guess what I'm wondering is why everyone talks about a plug in architecture?

Having the ability to code python scripts is the most powerful "plug in" of all, and given a STABLE API of python, (one which changes by gaining functionality, but doesn't break old functions), it would continue to be very useful.

After all, a plugin writer usually would need to know a programming language in the first place - python is one of the easiest languages to learn for anyone, in my opinion, and it is an extermely powerful language, more powerful than just crappy plain C or Perl or languages like that. You would still have the API, the "blender plug - in interface" for the python code. Even now that exists. All people would need to do is add more functionality to that API.

To be honest, I think some use the words "plugins" as a buzzword. It just sounds cool.

Most people don't realize how awesome python really is until they dig in and taste some of it. It even forces code style on you - formatting is part of the code. Python is very clean.

The biggest benefit is the python isn't compiled, and it will run on all blender systems. One file, multiple users. HMM. .NET in its own form eh?

Aw, well, I guess that if someone actually wrote improved support for VL, anyone would be free not to use it if they didn't like it... Just as I'm free not to use NURBS if I don't want to, even though it's there for those who need it. When it comes to reasons for using raytracing, I'd say that line of reasoning is kind of off target. It's really all about the freedom to use another renderer, no matter what type it is.

And on the topic of Python as a "plug-in-language" it's totally OK if the API was complete. Is anyone working on this, or planning to? Oh, yes, Python is an excellent language, and incredibly powerful too.

Aqsis appears to be a plain vanilla renderman compliant piece of renderer with a standard feature set. I have not yet seen anything impressive made with it (if someone got something, post it please!).
The thing about VirtuaLight is the fact that it supports such an incredible amount of possibilities. It's a lot like Blender - complex, flexible and extremely well thought out. That's why VL is such a good choice. And there is actually a Linux version planned. Don't know when it's supposed to be released though, but it's coming.