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.

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

.
Booooo!

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.

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"

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.

There are nearly as many opinions on where to draw the line between a model and controller as there are sites using MVC (and each framework implements MVC in a way that reflects an opinion on where that line should be drawn). CI does tend to lend itself to fat controllers, and I will often start with a fat controller and thin it out over time (for instance, the data requirements for a given portion of the site may not be clear initially, so the model(s) may not be implemented until later). I tend to think that any repetition may be an indication that the repeated code is in the wrong place, but this doesn't always help clarify where the code should reside.

I really like how you expressed this. Well-said!

In your case, since much of the code may already be written, it may be best to start with setting up the routing and some controllers to interface with the existing code (utilizing an autoloader or wrapping the code into libraries and/or helpers).

Working on this. Hoping to resolve Registry and Notification functionality first.