Are the features you listed built-in features, or plugins?
They're "built-in" the fact that they're maintained with the same vigour as the core code, but they're plugins in that they can be disabled (and their code removed from an installation).
remember-me is pretty standard, but perhaps in a case where an application didn't need or want it, it would be nice to be able to remove the feature with a simple commenting out of the addPlugin() line.
Ideally, people using the library won't have to modify the source files
at all. I'll be quite insistent on this.
It would be almost impossible to tailor the Authentication to every single predefined database type and table. The issue also is do we assert our own brand of authentication setup?
We do both. I've been thinking about this a bit, and there's two opaque layers (three, if you count PHP's system level functions, but those aren't overloadable). At any point in the layer, an advanced user can override functions to deal with their particular use case. Starting with the layer our class will interface with:
1. Action-oriented (bad term!) database wrapper, acts sort of like a facade except the fact that it contains some pseudo-SQL stuff. It contains methods that each represent an SQL query, like 'getUserFromUniqueHandle()', etc. The SQL it contains is pseudo because it doesn't actually contain the "real" column names, like "SELECT :user_id, :password FROM :table WHERE :user_handle = ?"
2. Lean DB wrapper. This actually executes the SQL and performs not only value binding but table/column name binding (in the upper case, the column bindings are textual while the data bindings are question marks). The user is able to extend the default case and inject his own column names into the class definition so everything is hunky dory.
I'd write code but I'm pressed for time. As long as compatibility problems aren't too bad, all the user has to do is configure a lean DB wrapper to process the queries for their particular schema. If they're actually writing/reading plain text, they can totally overload the action-oriented database wrapper.
You're still thinking in "Self-contained application" mode.

This is "extending classes" configuration, not "pass an array" configuration.
In fact, the Lean DB wrapper doesn't have to know any connection parameters (although that would be nice). PHP's mysql_* functions have a nice feature where if a resource handle isn't specified, it'll use the last opened one. Most scripts only have one database connection. If the user is purist enough to object to this sort of trickery, let them tell the lean DB wrapper where to find the resource.
I hope this solves the problem. Maybe I missed something.
had a small epiphany
You're correct on all counts. (although, unfortunantely, that's what I believe I was arguing about the last few pages. But that's okay). Your distinction between authorization and access control is, however, quite novel. Never thought of it that way before.
I am seeing the system as several middle-men that make up the framework and modules that are provided by the application (Credential Acquisition, Authorization Rules, Datasource) using the conventions and interfaces we define.
We can provide standard Credential Acquisition (login form, captcha, cookie remember me), Authorization Rules (deny/allow all, is logged in, in group, has permission/role), Datasource (database, LDAP).
If anyone cared to take a look at the OSID links I posted above, people have already created interfaces for these problems. What they failed to do was provide working code (actually, I haven't checked, but I'm most definitely sure not code for PHP!) I cannot stress enough the importance of maintaining the code we provide.