in reply to On naming of XS extension modules
Assuming an OO module Foo::Bar, I think the cleanest way would be a frontend with exactly that name. The frontend loads either Foo::Bar::XS or Foo::Bar::PP, then modifies its own @ISA accordingly. By default, the XS should be loaded, with a fallback to PP. There should be a way to force using XS or PP, at least for tests (something like use Foo::Bar -usePP; / use Foo::Bar -useXS;). Shared code and user documentation goes into Foo::Bar, the Foo::Bar::XS and Foo::Bar::PP modules contain only XS methods or their pure perl replacements. Users should not need to know about XS and PP. Code for both should be in the same archive. The installer should make the module work (i.e. install at least frontend and PP backend), preferably fast (i.e. compile and install the XS backend if possible).
For non-OO modules, the backend modules have to export their functions into the frontend, from there, they can be exported to the user code.
A different approach could be copied from File::Spec::Functions, offering an OO interface and a wrapper that offers a function interface, either in a separate module (i.e. Foo::Bar::Functions) or integrated into the frontend module à la CGI.
Alexander
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)