CI4 User Authentication System

This will be treated primarily as a model since it requires MySQL database access. It will have basic templates for controllers and views that for users to start from, if needed.

Here is a current list of goals for initial release:

• Create a website for communications and discussions
  
• User login and registration
  
• Password recovery (forgot password, username, etc)
  
• Login attempt logs with IP address tracking
  
• Lock out users for specfied amount of time after a number of failed attempts
  
• Generate email messages that can be insert into the developers email method of choice
  

So ... an already working application, without the business logic in it.

From you issues:

Need to determine what packages to include in final release.

   Password hasher
   Any Security packages
   Emailer

Should also determine if these packages should be included in the UserAuth namespace or within their own namespace in the CodeIgniter application.

The bolded line in that quote is the real problem ... Security isn't a thing you install.

...

Password hasher? What's wrong with PHP's native password functions?

Nothing.

But, while the OP probably listed that for the wrong reasons, there's plenty of room for abstraction on top of PHP's ext/password.
So, here's a shameless plug: https://github.com/ITCover/PasswordProcessor (the README explains what I mean)

Take 'forgotten password' for instance. There are so many ways to do just that alone. Secret questions, emailing reset links, emailing codes to reset, sending temp passwords, second one time use passwords, sending random passwords, human moderation of password resets etc etc.

I'd argree on your point in principle, but have to disagree on this example ...

Secret questions are a no-go. Period.
Emailing password reset codes or links is very much the same thing.
Emailing temporary passwords is essentially the same thing as emailing password reset codes.
Temporary passwords must always be only for one-time use (hence the last point above)
Any password (or code/token) you generate must be random regardless of what you do.
Human moderation can be useful only in closed, intranet-style systems, but even then - don't forget that humans are always the weakest link.

So ... You drop 2 of these (first and last), see that another 3 are the same basic thing (one-time token/password) and then note that the only remaining thing is a requirement for the former basic thing.
Not much choice really.