my premise that Perl is inconsistent

Perl is far less inconsistent than you think. I won't say it's entirely consistent; there are a (very) few places where it is defined & documented to be inconsistent, and those are there for convenience, i.e. to make Perl DWIMish.

But these aren't that. Perl may seem inconsistent, in the things you've demonstrated, but it's not; you just need to know what Perl is doing. E.g. know the difference between use and require.

Most "inconsistencies" I know stem from the Perl4 to 5 switch.

Concepts where kept in the language for backwards compatibility but were "discouraged" (Well kind of)

This allowed a smooth transition for old code bases, but resulted in a lot of mental overhead and Perl getting a bad press.

At least the perldocs should have been straightened with a clear philosophy, unfortunately it's often a maze. And many core modules show still the old mindset in their docs, like Exporter

And these discouraged features still needed to be maintained, which made adding new features without breaking old ones a major headache.

It's not an easy process...Perl6 tried to break with backwards compatibility, the result is known.

Cheers Rolf
_{(addicted to the Perl Programming Language :)
see Wikisyntax for the Monastery}

or even why the concept of code that "works" is so bemusing to you it needs to be quoted

See How to ask better questions using Test::More and sample data. You have not even described what "works" means in the context of the snippets you have provided. Both run to completion so it is left for everyone other than you to guess what you might possibly mean.

That's correct and consistent for any required module, because you use a full qualified path to the function which was loaded.

I'd call this bad style in the case of a general module like POSIX though, because there is no harm in explicitly reloading it again if needed in the current module. It's an NO-OP if it's already loaded, and essential if not.

There are groups of modules/classes which are so deeply intertwined that it's not only OK but explicitly documented in the main module, to make calls to dependencies.

The magic word here is explicit

As purely a side note:

I stuffed a lot of date/time/datetime/timestamp code i use into wrappers in a central module of my framework. It's not the best for performance, but it helps during testing. It's quite astonishing for how much timestamp based crap you have to test in commercial 24/7 applications, including leap years, DST changes etc.

And plainly wrong system times, because some clueless admin didn't understand NTP and firewalled it. And just playing with the system time isn't enough, because the database server in production might have a different time than the application server. During dev, everything runs on a single laptop, so i need a single place where i can fudge the time functions in Perl, so i can test if i accidently mix local and remote timestamps...

PerlMonks XP is useless? Not anymore: XPD - Do more with your PerlMonks XP
Also check out my sisters artwork and my rather simple sketches/one-panel comics

I think you are referring to loading a bunch of modules at once to avoid boilerplating.

Again, that's ok as long as it's explicitly documented.

And normally it's only a "dependency of second degree", looking into the container module will directly reveal the target modules. And (hopefully) the container will have a clear name.

I've seen some counterexamples in my work life with "try and error" code which was considered "working" because it didn't fail at time of coding.

Cheers Rolf
_{(addicted to the Perl Programming Language :)
see Wikisyntax for the Monastery}