overall code organization: helper, library, core, or model?

CI v3 supports Composer if you enable it via a config value, so that would probably be your best bet for an autoloader, though it presumes the code you need to autoload is compatible with Composer.

I'm not especially familiar with Composer, but understand that it's a command-line tool that is essentially a package manager. Could you elaborate? I expect I'll still need an autoload function regardless of whether I use composer or not.

Composer is both a package manager and an autoload function. The command-line tool reads the composer.json file in your project and pulls in the packages, then generates an autoload function for those packages. CI includes a configurable option to call the Composer autoload function, or you can call it yourself in your project's index.php file (since CI may load it later in the application than may be desired for some uses).

I've used a number of static libraries with CI which simply include a non-static constructor for CI to call.

.
Booooo!

...and we could digress into a discussion of the questionable nature of static libraries in PHP, which does not support static classes in the first place. I think we can just agree that it's annoying and move on.

A helper is usually just a group of related function definitions with no class definitions.

Thanks for clarification. Potentially useful, but also seems like a good way to invite name collisions.

In some ways, you could think of a helper as a prehistoric namespace (or even class) mechanism, except that the functions are still defined globally. In most cases, every function definition is wrapped in an if (! function_exists()) call, and one of the more interesting features of CI is that you can define a MY_xxx_helper which provides your own definitions of functions defined in the CI xxx_helper, providing an override method for basic functions.

Yes, name collisions are a constant hazard in a CI project, but in most cases they're not as common as you might expect.

The libraries directory is more or less a catch-all for classes which do not have an easily-defined place in the MVC structure.

Seems to me like 'libraries' is a good place for third-party libs. I.e., "code that is not of my creation" and also "code I created which I reuse for many disparate projects"

Yes. There's also a third_party directory which can be used for many of the same purposes, but offers some additional support for overloading core classes. As with everything in CI, there is almost always more than one way to do something, and very few things have one distinct right answer.

in my own site I have a number of models involved in handling notifications, though the notifications themselves are triggered by various models (as part of an insert or update, for example) and even by a library in some situations (e.g. retrieve and display notifications when a user logs in).

How do your models and libraries gain access to your libraries and models then? Seems to me the default loading behaviors in CI rely on the sharing of a fairly heavy CI object which serves as some kind of referential conduit so that the various pieces can all locate each other. It's like the CI object is a spine or hub of some kind.

More often than not, I take the approach of calling $this->load->library(my_library) or $this->load->model(my_model), which attaches $this->my_library or $this->my_model to the corresponding object. If I want to avoid that, I can still use any number of other methods to load and pass objects. In most libraries, the CI object is only pulled in when it is needed, using the get_instance() function to get a reference to the CI controller. If the CI reference is heavily relied on, the library will usually define a property which will be set to the reference and used as required.

If you start digging into some of the CI core code, you can see that the spine/hub metaphor works fairly well. CI starts out by loading up several key components, then it loads the CI_Controller. The CI_Controller attaches all of the CI components which were previously loaded to itself, then loads and initializes the Loader, which loads all of the classes configured to autoload (and the loader usually attaches each loaded class to the CI_Controller instance).

If everything is done properly, CI_Controller behaves as a large singleton which gives you access to most of CI's functionality, usually exposed through $this (because a controller will generally extend CI_Controller and the CI_Model includes the __get() method which references the properties and methods exposed through get_instance()).

Bonfire

Practical CodeIgniter 3
CodeIgniter Testing Guide