itimpi

On the Main tab do the emulated drives now mount but still show a red 'x' indicating that the physical drives are still disabled (which is what I would expect.). 
 
If it is something else then please describe what (or provide a screenshot of the Main tab).
 
If so then to clear the disabled state you will need to rebuild them so that the physical drive matches the emulated ones.   If you want to rebuild the disks back to themselves then this is covered here in the online documentation accessible via the Manual link at the bottom of the Unraid GUI.

Not quite.   You have omitted steps and added one that should not be there.
 
Step 1 Should read
1.1 Insert new disk and start server (without starting array). 
1.2 Use Tools->New Config and use the option to preserve existing assignments
1.3 Return to Main tab and change the assignment of the problem disk to be the new disk
 
Step 2 should not be there so do NOT format the new disk.   You are likely to end up formatting the emulated drive and this would lose the contents of the problem drive.  The rebuild process later will put the correct file system onto the new disk.
 
Step 4 should read
4.1 Stop array
4.2 unassign the new disk
4.3 Start the array to get the disk slot into being emulated.
 
Step 5 -should read
5.1 Run the check filesystem procedure to repair the emulated drive.  At this point if the repair is successful then it will be mountable the next time the array is started in normal mode.
5.2 Stop array
5.3 assign new disk back to slot which is being emulated and has now (hopefully) been successfully repaired.
5.4 start array to rebuild the emulated contents onto the physical drive.

You can either read the GUI built-in help by clicking on the text for the setting, or a fuller description here in the online documentation accessible via the ‘Manual’ link at the bottom of the GUI or the DOCS link at the top of each forum page. The Unraid OS->Manual section in particular covers most features of the current Unraid release.

It is quite normal for both parity drives to be rebuilt at the same time after the actions you say you took.   The New Config tool always assumes by default that the changes you made to drive assignments will invalidate the current parity drive(s).
 
If you think about it in normal running any time you write new data both parity disks have to be updated accordingly so writing to both of them at the same time is quite a normal occurrence.

Try removing the Mover Tuning plugin and then try again.

Try removing the Mover Tuning plugin and then trying again. 

According to the diagnostics you currently have 24GB on the cache:
/dev/nvme0n1p1 466G 110G 356G 24% /mnt/cache and several shares have files on the cache
appdata shareUseCache="prefer" # Share exists on cache domains shareUseCache="prefer" # Share exists on cache isos shareUseCache="prefer" # Share exists on cache P-------A shareUseCache="yes" # Share exists on cache, disk1, disk2, disk3, disk4 system shareUseCache="prefer" # Share exists on cache, disk1 t--t shareUseCache="yes" # Share exists on cache, disk2 t-------e shareUseCache="only" # Share exists on cache
need to give more detail as it looks from that as it looks as if cache is actually working.
 
in practice you want to get all of the ‘system’ share onto the cache to maximise performance.   To do so you would need to temporarily disable the docker service and then run mover manually.  After doing that you can re-enable docker service.

The way devices are counted has not changed.   There was no point in the past that I can remember where Unassigned drives that were present at the point the array is started were not counted.  
 
You can use the Unassigned Devices plugin to temporarily mount drives beyond the limit (e.g. for backup) but they need to be removed again before the next time the array is started (typically after a shutdown or reboot) to keep within the licence limit.   If you are over the limit you will not be able to start the array.

It will know as long as you put them into the Movies Share on the cache drive.   In other words mover simply mirrors the path on the cache drive to the array and does not look at the content of any files.

This is the recommended way to handle this so the server thinks it is hardwired and the extender handles the transition to WiFi.
 
Not certain, but I suspect that there are several reasons:
Many people are focused on speed and WiFi is typically significantly slower than wired (although this is becoming less true with the latest mesh systems). Unraid loads into RAM and then runs from there, so including support for any significant number of WiFi chipsets is likely to significantly increase the RAM footprint. End users cannot simply install drivers so the central Unraid team has to invest time and effort any time a new driver is to be included into the next Unraid release. All of this is supposition though so there could be some other driving factor.   It would be nice to have it as an option, but as you found using WiFi extenders is a simple workaround.

The standard handling of disks going unmountable is covered here in the online documentation accessible via the Manual link at the bottom of the Unraid GUI.  In addition every forum page has a DOCS link at the top and a Documentation link at the bottom. 

Looks like the docker.img file (in the system share) is on disk1.   That means that any time the docker service is running those two drives will be spun up.  Ideally you want all of the 'system' share to be on the cache both for best performance, and also to let the array drives spin down.

Have you stopped the array before trying to assign the replacement disk?   Your description makes it seem you have may have omitted this step as if you had at that point the disk would not be showing as 'emulated' and you would not have the other disk under Unassigned Devices.?   If that is not the case then please post your system's diagnostics zip file after attempting the replacement so we can get a better view of what is going on.
 

You should post your system's diagnostics zip file in your next post in this thread to get more informed feedback.  It is always a good idea to post this if your question might involve us seeing how you have things set up or to look at recent logs.
 
My suspicion is that that is the amount of space used on the drive where the docker folder is located.
 

Looks like you have macvlan enabled for docker networking and bridging enabled for eth0.    This combination is known to cause system instability.    You either need to switch to using ipvlan for docker networking or disable bridging on eth0.   This was mentioned in the 6.12.4 release notes.

No data drive can be larger than the smallest parity drive so you cannot currently use a 16TB drive to replace the failed data drive as parity! Is only 12TB.
 
You can use the parity swap procedure to upgrade the parity1 drive to 16TB and then use the old parity1 drive to replace the failed drive.   It is specifically intended for this Use Case.
 
Alternatively you can simply upgrade parity1 to a 16TB drive and when that completes use another 16TB drive to replace the failed drive.
 
the first approach is definitely best if you want to end up with 3 data drives.

If you used New Config then you should let the parity sync complete unless you are absolutely certain that parity is already valid.

As long as it is configured to access its files via a User Share Plex will not be aware of whether any particular file is currently being cached on a pool or is on the main array.

You may find this section useful from the the online documentation accessible via the ‘Manual’ link at the bottom of the GUI or the DOCS link at the top of each forum page.  

It is unlikely to make any discernible difference as I am sure even the slower SATA port will have much higher throughput than any HDD can support.

OK.
 
Worth pointing out that not all flash drives DO have a unique GUID (which is a requirement for Unraid).  This is particularly the case if the drive is a 'fake' or one of the very low cost brands.   It tends to be obvious when looking at the GUI as it contains sections that are all zeroes or something like 12345678.

The automated transfer can be done once per calendar year.    For any transfers more frequently than that you need to contact support.
 
i see no reason not to continue using the SanDisk flash drive.   I have some that I have used for many years.   The only problem with SanDisk is that they are a brand that is one of the more commonly ones counterfeited but if you have a genuine one no reason to suspect there will be a problem with it.

Yes.
 
Remove the drives via the New Config tool snd make sure you do NOT tick the parity is valid checkbox.

Run without -n and adding -L.

For mover to run the share neeeds to be set up with the cache as the primary storage, the array as secondary storage and mover direction as cache->array.   From your description you have changed the share settings so that it has the array as primary storage?   If so mover will take no action on files that are alreadt on the cache.   The diagnostics will confirm if this is the case.