First of all I should note that Exporter offers export_fail which can be used for the same purpose.

Yes, but while I am currently overriding import and removing the two items from the list, in this case I would override the export_fail method and remove two items from the list there. As I see it, both implementations are similar, but I will take a look at Carp.

(It reports errors at the wrong level.) Therefore this alternate strategy may be more reliable.

Agreed. That makes for better diagnostics.

There was an excellent article on perl.com explaining prototypes in Perl and demonstrating why they are problematic. ...

Oh no! Has the camel misled me? Are prototypes not what I thought? I do enjoy the diagnostics on erroneously constructed sub calls, but is there a downside? I couldn't find an article on perl.com about this. Is there a PM article containing same? I couldn't locate one.

I also have to second perrin's comment. While playing around with export semantics can achieve all sorts of cool effects, unless it is really important for what your module does, it is better programming practice to stick to normal export semantics and not overload your export semantics.

I wouldn't say it's really important for the module, just a stylistic preference, with some notion of clean-looking client code.

Thank you. I appreciate the considered response.