I like the idea of porting hotspots, but keep in mind that we want people to be able to use this even if they don't have access to a C compiler.
That's going to be a problem with any non-PHP code, to a greater or lesser extent, but there's no reason someone can't maintain a (now modularized) native-PHP parser.
A possible middle road is to rewrite the core wiki engine to a separate daemon, and adapt the existing PHP user interface to call into it for much of the backend work that actually touches data.
I like this idea, although it carries its own costs. In particular, communicating between processes has inherent overhead; we'd have to be reasonably sure that the caching would outweigh that. Also note that IPC and process-management mechanisms tend to vary across operating systems; we might lose Windows support, for example.
I'd like to see as much portability maintained as possible, but to be honest, I'm not personally worried about it. MediaWiki is, first and foremost, the software that runs the Wikimedia projects. I can't see us running Windows on the cluster anytime soon.
One advantage of this split is that we could rewrite one of the components in another language if we want, without affecting the other one. If the front end becomes little more than a shell around a daemon, we could provide a version written in C as an Apache module, which is about as fast as it gets.
There are numerous options available to us, and that's one of them. Making MediaWiki the server itself is at the far end of that extreme, and the are countless possibilities between it and the other.
On the back end, Perl 6 is specced to have one of the most powerful pattern-matching engines ever shipped with a language; it should be able to eat wikicode for breakfast. It's also designed to allow easy interoperability with other languages, so just the wikicode parser could be written in it while the rest is left as PHP. Implementation is moving quickly, with the backend Parrot Grammar Engine in progress and the Pugs (Perl 6 in Haskell) compiler just starting on the syntax. (And, of course, you'd have a very happy Perl hacker here.)
I've yet to be sold on Perl 6, but that's just my personal opinion. It may yet turn out to be the best option, especially if its pattern-matching capabilities are all the evangelists say they are.
-- Brent 'Dax' Royal-Gordon brent@brentdax.com Perl and Parrot hacker
At least you're open about your bias. ;)
-- Austin