In previous Drupals we had a rough version of plugins -- you could load a cache plugin instead of cache.inc but that was all. The pluggability was on file level and it only existed for very few files. Drupal 7 introduced many more pluggable subsystems and now the pluggability happens on a class level (mostly). We can plug in sessions, cache, queue, field storage, password hashing... Crell is working on unifying these for quite some time now. And this is all good, however, for Drupal 8 I would like to see a lot more. I mentioned field storage already -- that's an install time decision because moving content from one storage to another is not trivial to say the least. If we have install time decisions on plugins then we could use the install system to compile files for us with the desired pieces swapped in. Edit: for example you could replace a function with an alternative implementation from a contrib instead of actually hacking the file. Updates are still easy just need a recompilation step -- thanks to the new upgrade manager that'd not be too hard either.
Also, this can happen on packaging time as well, so the ordinary user never needs to touch it. Yay for profile hosting on Drupal.org :) More, we can use PHP streams to include code from database! Which can lead to the same thing: pluggability on any level we want. I will write more why we want that, stay tuned!
I'm not convinced that "compile-time" pluggability is worth much. It's really only useful if you're doing merge-to-one-huge-file type compiles of Drupal, which are (and should be) a rare edge case. That said, making more things cleanly pluggable is just good practice in general for many reasons. That it would enable such edge cases as this is one of the benefits, but there are many many more.
Actually, I just realized something else about the compile-to-one-file approach. That's only really viable if we don't need to manually load files, because we'd then need to remove the manual load (require_once et al) calls when merging into the one big file. PHP has a built-in mechanism to do that for us, however: Class autoloading. If we rely on autoload to load code for us, then making the class we want available before Drupal needs it (via compile-to-one-file or implementing it in C or whatever) neatly bypasses the explicit load and means we need to modify no other code to make it work. So it sounds like using OO for such pluggability would make the entire process easier. Hmmm...
I am talking of swapping pieces of a given file.
How would opcode caches react when you'd pull code from the database?
I think it would be a major performance setback.
APC can be configured to work with this.
oh noes, please forget about storing and loading code from the DB.
It's unmaintainable, not versioned, invisible, and overall totally unmanageable.
There are a couple of applications that allow this (f.e. vBulletin), and if you ever worked with them, then you know that you absolutely do NOT want that. Regardless of how dynamic, interesting, and funny the idea might be.
On development you would use file-based compilation and put it in a DB if you want on deploy. Also? This is just a blog and we are discussing :)
Not to mention how maintainable it will be will all the hacked plugins in place. Upgrading would be a nightmare.