The actual cue file and the actual music file (the bulk file/disc image file) are not imported. If I do a search now for cue files in my library it will come up with zero.
Right. Because the CUE files are playlists, not media files. They define the "virtual assets" in the database. Both the CUE and bulk media files
are imported, they are just represented in the database by multiple media files. This is no different than importing a M3U playlist file, except that the CUE file points to different sections of the same media file (typically) and a M3U file points to multiple discreet files on disc.
If you have M3U files in your import path, and the Playlist file type grouping fully enabled, MC re-scans these at each import too. I thought originally that you could disable this by disabling the Update for External Changes option, but I was wrong. I re-tested before I posted the above, and it re-scans all playlist file types each time. This makes sense as they are, by definition NOT media files, but playlists. When you import other playlist type files, those also don't show up "directly" in the Library. They are converted to MC's type of database-Playlist and put under Playlists in the Tree.
1. "Searching for files..." (MC browse the folders for something new)
2. (NEW!) "Checking/Adding Playlists and Cue files..." or something (The counter starts ticking when MC checks through playlists of all kind - in my case this is where it would count to 1614)
3. "Adding files to the library..." (A new counter starts showing only newly added files to the library)
Sure. That would be, logically, more understandable. However (I'm not positive, but from the work I've done on MCFileIngester, I believe that) architecturally, MC's Import engine doesn't distinguish between #2 and #3. It basically does this (for any full Auto-Import run, background runs work differently):
1. Filters the list of all files in a Watched Directory against enabled File Types for the Import.
2. Checks this list against the current files in the Database.
3. Any completely new media files get added to the temporary "Import Queue" list.
4. If Update for External Changes is enabled, then it also adds any files that have a date modified date newer than the last database update timestamp for the file in question.
5. Any playlist format files it discovers are added wholesale to the Import Queue list. It has to do it this way because the search engine does not read files from disk (just looks a filesystem metadata). To know if there are new files in Playlists, you can't just look at the filesystem metadata (mostly the filenames on disk), you have to actually open and read each file. Reading files is done by the Import engine, not the search part of the engine.
6. All of the above is the "Searching for files" part of the process. That search is fast precisely because it doesn't read any files off of disk at all, just filesystem metadata. When the search is done, it hands the Import Queue list it built to the "Import Engine".
7. The Import Engine reads each file in the Queue and each file is either imported fresh (if it never existed previously in the database) or, if it exists already, the metadata in the entry for the file is refreshed to match the on-disc data.
You're looking at it like "importing" is a one-time thing, and that updating the Library is a discreet operation. While this makes sense logically, I think technically those two things are done by the same code, and are, as far as MC's components are concerned, identical operations. It is reading the file from disc and updating the database. Whether it is adding a new row to the database or updating an existing row is pretty irrelevant.