I've tried out 1.5.2 (HDRP). Looks like the fix for not deleting Animations and Prefabs works properly. However, the imported animations from _Motion.fbx files still don't generate with blend shapes. I'm not sure if there's some trick or setting I need to get that to work properly. If it would help, I can share the CC project (and resulting FBX files) with you.

Just the FBX would do and the .json file. Textures aren't needed.

and/or steps to reproduce this with a stock character.

This is easy to reproduce on a stock character. Here are the steps:

Aha! ExPlus are different blend shapes with different names (Part of the CC3+ Traditional profile), which Kevin doesn't have.
But also following those instructions, the separate _Motion.fbx files exported from CC4 have no blend shape tracks in them.
So CC4 is not exporting the separate mesh and motion files correctly for iTalk animations.

As the _motion.fbx files have no blend shapes tracks in them, there's nothing to retarget.

(Until recently adding iTalk files to the export caused it to fail in CC4, so there could still be bugs there.)

What does work is loading an iTalk file onto Kevin in CC4, which forces CC4 to retarget it correctly, and exporting it individually with export current animation (even as just a motion only file).

Ah, interesting. I'll report it as a bug, in that case. I did try the export with "Traditional" instead of "ExPlus", but it didn't seem to change the result; the original _Motion.fbx animations don't have any blend shapes.

Thanks for looking into this. Hopefully this means that if Reallusion fixes the bug, the importer will just start doing the right thing at some point.

On the topic of the importer not breaking references to things, there's one other place I'm aware of where references get lost. I'm really not sure how to go about preventing it, but it's related to the "_Extracted" meshes that the importer creates. The issue is that any references to those SMRs by other components will get lost whenever the importer is run. As a simple example, here's a component that references the SMR:
75% of original size (was 672x19) - Click to enlarge

Now I re-run the importer, and the reference is lost:
75% of original size (was 672x19) - Click to enlarge

I'm not sure how this can be addressed. I'm not aware of any Unity API says, "Any references to FileID X should be replaced by FileID Y". I also don't believe it's possible to manually set the FileID of a Unity component. All I can really think of would be editing the raw YAML of the prefab, replacing the new FileID with the old FileID to keep references alive (which isn't officially supported or recommened by Unity). Or some kind of fairly clumsy event that can be fired after import that says "FileID X should now be FileID Y", and leave it up to listeners to write code to fix up references if they want to. Neither sounds great.

I guess the simplest thing would be to actually load the existing prefab, rather than creating a new one, when importing (perhaps optionally). I'm curious if that was ever considered? I can see how that might make things a lot more complex, because now you'd potentially need to delete things from the existing model if they no longer exist on the FBX. Maybe I'll poke around in the code and see if it's possible to open the existing prefab, and only create new _Extracted SMRs if they don't already exist...

A small issues I noticed on some hair meshes. It looks like some hairline meshes need to have Alpha Clipping enabled, otherwise they have a weird effect. This probably happens with various Hair elements, but in this example I'm using the "Messy high" hair element.

To observe this, create a new project and add Camila to it, then replace her hair with the "Messy High" hair:

75% of original size (was 672x19) - Click to enlarge

Export the FBX for Unity, and import the character using the CC/iC importer. Drag the prefab into the scene, and look closely at the forehead. You'll notice that there seems to be a weird square pattern. Here's a screenshot, 

75% of original size (was 672x19) - Click to enlarge

It's more obvious if you change the skin color to something dark:

75% of original size (was 672x19) - Click to enlarge

The issue here seems to be that the "Messy_high" SMR has a "Hairline_Transparency" that is causing this shininess. If you disable the "Messy_high" smr, the issue goes away (but so does the hairline). If you enable Alpha Clipping on the "Hairline_Transparency", that seems to correct the issue, but I don't know if that's a general solution.

I have a question about Normals on models. I see that the importer forces a particular configuration on Normals (Calculate, Smoothing = 120). This causes some major issues with props/accessories that the character is wearing. For example, here's a jacket the character is wearing, when Normals are set to Import. Note that there are many "sharp" lines on the mesh:

75% of original size (was 672x19) - Click to enlarge

But as imported by the CC/iC importer, using Calculated normals and 120' of smoothing, this is what it turns into:

75% of original size (was 672x19) - Click to enlarge

All the sharp edges are lost, and there are weird issues. I'm curious if there's any solution to this. I guess it's complicated to try to enforce the same Normals approach to both the character and the outfit. But losing all custom Normal info on all outfits seems kind of unworkable.
Do you have some specific examples of how Imported normals look bad? The code comment just says "// import normals to avoid mesh smoothing issues "

It's because of the blend shape normals. Unity seems to be incapable of importing them correctly.

The base mesh normals import correctly, but the blend shape normals do not: Try setting them both to import and watch what happens when you change the facial expressions.

So the blend shape normals need to be re-calculated, *but* the calculation is so different from the imported base mesh normals that any and all facial expression blend shapes look really bad. Artefacts appear all over the face mesh.

Leaving the only consistent way to import the normals is to recalculate both, but this trashes the custom normals.

The fix, supposedly, is to set both normals to Import, and then enable Legacy Blend Shape Normals in the model importer. But this cannot be set automatically via code, it can only be done by hand.

That's really helpful. Thanks for pointing it out. I tried enabling that, and things do look fine with respect to both the character and outfit normals. I'm not sure if I'll notice some issue eventually with this setup, but for now it works.
As for not being able to set "Legacy Blend Shape Normals" in code, that's an interesting oversight by Unity, unless they're deprecating this setting and don't want to encourage its use... However, I can at least confirm that if you manually enable this once, it remains set from that point on. So at least it doesn't need to be manually re-ticked every time I run the CC/iC importer. But it does mean I've made an edit to the importer to allow it to leave "Normals" set to "Import" instead of "Calculate". I'm not sure if there's a general way for the tool to make that optional, though I would admit that starts getting a little confusing. 

Thanks for the easy fit.