Generally, the commonly given advice is not to export anything by default. I.e. everything goes in @EXPORT_OK, nothing goes in @EXPORT, and it's helpful to include some sort of :all or other subsets in %EXPORT_TAGS. I think that's your option (2). The benefit is that it gives the most flexibility to your end-user. They can use fully-qualified names if they prefer, or they can import the function if they'd rather use a shorter name. I would find it annoying if you didn't put your functions into @EXPORT_OK and give me the option (and I'd probably just wind up doing my own aliasing if I was using a function frequently anyway).

What I believe is a common exception to that guideline is the case where a module only provides a few functions (or even just one!) and the whole point of the module is to make those functions available for frequent use. (E.g. Test::More and most of the Test:: modules.) In such cases, I personally think that putting these into @EXPORT is the right thing to do.

So my guidance is to think about what would be the most likely usage of the module and let that be your guide. If there are functions that 9 out of 10 users would import anyway, stick those into @EXPORT. Otherwise, put them all into </code>@EXPORT_OK</code> and include at least an :all tag.

(Note: I'm only speaking to function names above. I'd never advise automatically exporting package global variables and would discourage using even fully qualified package globals as an "interface" mechanism to your module.)