will we still have that ability [...] to interface with existing C libraries

Of course we will, and it will be much, much easier. For starters, check out Parrot's Foreign Library Access. You can open a shared library, DLL or whatever, and then just start using it. Parrot already has a fair amount of smarts to let you specify the calling conventions. Many XS problems will simply vanish because of the level of support that Parrot provides intrinsically.

And if Parrot can do that, you can be sure it will be easy to tap from Perl. And it will be Good.

Hmm...somehow, I doubt that it will be as easy as the doc you pointed to suggests. If it were that easy, why haven't C compilers gotten rid of the need for header files? Something tells me that you'll at least need the header file.

thor

Feel the white light, the light within
Be your own disciple, fan the sparks of will
For all of us waiting, your kingdom will come

As a developer of the glue code, you'll need to have intimate knowledge of the function signatures and data structures contained within the header file (assuming you're gluing some existing C library to perl). But once the glue is developed, you won't need the header file at all because all of the info will be in the parrot source file or the perl6 module. In other words the C header file becomes a perl and/or parrot source file. Writing in perl for extensions is a whole heck of a lot easier than writing some in perl, some in C and requiring a C compiler.

duff

I can't imagine it - even the Java purists put in JNI, albeit somewhat reluctantly (at least the way I heard it). I can't currently find the reference, but I'm pretty sure that when I read that XS was "going away", it was being replaced with something simpler. Which would be quite welcome here - the learning curve for XS has been a bit too much for my tastes so far.