While optimizing for performance, I think I've uncovered why Blender is distorting the UVs during the cell fracturing process. The window on the left will have distorted UVs while the one on the right will not and I suspect it has something (everything?) to do with the fact that the coplanar UVs are split along the corners.

Performance seems to have definitely improved after making the following edits:

1. Disabled CastShadows, ReceiveShadows, & UseLightProbes on all meshes and fragments where applicable.
2. Set a handful of shaders from Standard (Spec) to mobile diffuse.
3. Separated shutters and swinging doors into two separate occludible GOs. 

While the performance definitely seemed improved, it bears mentioning that the jail and hotel were completely disabled during this test.

 Working on optimization now. Thus far, controlling enabling and disabling of the fractured objects has worked well, but the FPS still has noticeable hitches from time to time--namely when the camera pans from stage to stage & also the hotel due to the sheer # of fractured objects. Reports (from Harry, done on the test machine) states that the FPS, "...actually seems to be doing very well, there's a few places where the FPS will drop for around 40 if you've been machine-gunning with the shotgun..." A quick look into the profiler while viewing only the saloon indicates that the drawing of opaque geometry is taking the longest to process, with physics.processing, and the animators.update being 2nd and 3rd respectively

I'm thinking the following: 

1. Disable the shadow casting on all of the fragments (maybe disable receive shadows as well?).
2. Using a more simple shader on the secondary material of the fractured pieces.
3. Adding the ability to enable & disable the shutters and swinging doors one at a time.
4. Disabling the fragmented lg windows that are covered by shutters. 
5. Grouping together of multiple fractured GOs. This could be time intensive as it would require both placing & grouping unique building pieces together in Blender.

During the process of optimizing the meshes and maintaining material ID consistency (see previous post), I was merging verts based on a distance threshold, which while good, was still leaving a fair number of coplaner verts. For example, the verts on the right would be merged, but not the verts on the left.

In order to solve this, select all verts (from every fragmented piece), press delete, choose limited dissolve, and set the angular threshold. A value of 1 will suffice without compromising the silhouette of the individual fragments. 

Using this technique in addition to merge verts by distance, I was able to reduce the vert count from ~45k to ~30k on the trough mesh, which is quite a reduction :).

 Regarding fracturing, I am now addressing an issue that I've been aware of for quite some time but have yet to confront--the random reordering of Material IDs. This issue is brought to bear by the need to reuse the door mesh, which uses different, unique materials for the jail, the saloon, & the hotel.

Evidence of the swapped material IDs is exhibited when attempting to manually reassign materials to the individual fragments. ID 1 should be the facade of the door and ID 2 should be a generic wood, yet it can be clearly seen that this is not the case. 

After some searching I found this thread on the Unity forums indicating that on import Unity correlates vert/face values with material ID values. For example, whatever material the very first face (however that is defined) is using would be material 01, whatever material the second face is using would be material 02, etc. In essence, the specific sequential ordering of the faces directly affects the order of the materials on those objects, so despite the objects displaying the correct material ordering in Blender, the import into Unity does not. 

I found a solution here, and (in Blender) select all of the verts of every fragmented object and then "sort mesh elements" by material (ensure the "faces" option is selected). This will effectively reorder the faces according to materials, which is what we need. 

As a side note, I also merged verts by distance and was surprised to see that it removed 6000+ verts without noticeably affecting the mesh. I should do this for all fractured pieces and reimport.

Fractured enemy mostly works as expected, but the objectpooling creates a problem where already fractured targets will spawn. This either needs to be solved, or the fractured targets scrapped altogether.

 Let's see what happens when attempting to integrate a fractured target. The target itself has both a mesh collider and a rigidbody, which are typically not on the initial mesh, so I'm unsure whether or not that will create problems or even if those components will be necessary when all is said and done. Also, the cell fracturing may not play nicely with this complex of a mesh; typically it likes quads, and quading out this mesh could be a headache. Oh well, here goes...

 Going to set the convex flag for all fragments, maybe even replace the mesh collider with a box collider. See if performance is noticeably better.

 Box colliders instead of mesh colliders on the windows was apparently a not great thing as the BreakableObjects script specifically looks for a MeshCollider when disabling it on shot. I could probably fix this without breaking anything, but to be safe I'm not going to bother with it; at least, not yet. Anyways, as I said before, I imagine the performance benefits (if any) are negligible compared to the physics hit I'm getting on the fragmented objects. 

 Running into frame rate issues, which doesn't exactly come as a surprise. Spamming the P2 shotgun (the equivalent of 9 shots) & the sheer number of fractured objects on screen at any given time both seem to impact performance more than anything. 

I've already made a couple of adjustments--namely reducing the time until the CombineInstance function fires & drastically reducing the life time of the particle fragments--which seems to have helped, but the performance is still not where it should be. I've also replaced the mesh colliders on the window panes with box colliders, which I would assume is also less expensive, if only barely. Other than that, I'm not yet entirely sure how I'm going to handle this...

 Going back to the fence, which was one of the first, if not the first object that had UV distortion issues, and after a bit more reading and trial and error, I have come to 2 conclusions

1. there's something about tiling UVs that fracturing does not like. This can be solved by manually applying the boolean modifiers; however
2. doing so somehow affects the maximum # of fragments that the CombineInstance function can handle.

I know I've gone over this at least 1 or 2 other times, but I am increasingly convinced there may not be another practical solution without programmer aide. This also presents problems for larger objects, such as the entire facade(s) of buildings, which rely heavily on tileable textures. 

 Another window that will only be 250 fragments instead of the usual 400. It'll be interesting to see if this behavior continues on other objects. As of now it's only been the windows.

 Nevermind, Solidify changed nothing in that regard

 Trying something a bit different with this window, which also distorts the UVs at the corners. Instead of building the geo from scratch, I'm using the Solidify modifier. Can't see how that would make any difference, but I guess I'll know soon enough.

I'm still unsure where the problem is and I'm a bit tired of experimenting with this process, so for now I'm going to move on. On the bright side, I no longer need to convert all fragmented pieces into editable meshes in order to apply the boolean modifier; instead, I can use the Blender "Modifier Tools" addon which allows the simultaneous application of modifiers across multiple objects. However, this doesn't appear to fix the problem. While the CombineInstance function does work as expected, I can (for some reason) only use ~250 fragments. From previous testing I know that I should be able to use near 400 so there's something going on that I don't yet quite understand. 

Regardless, as I said before, I'm going to implement this window_med mesh using only 250 pieces. Perhaps the problem will reveal itself as I continue working? If not, I suspect 250 pieces/fragments will suffice.

~390 fragments works as expected, which means the DebugBoolean process is somehow mucking up the works... :/

Using the fragments with the UV errors (e.g. without DebugBoolean) and with only ~100 pieces, the in-game performance was as expected. Let's narrow this down

 In addition to the UV errors in the corners of the window mesh, I am still experiencing this error.

There are < 400 fragments, so I do not know why this would be, but I'm now wondering if the UV issues is somehow related and/or the cause. I attempted a whole new set of UVs, but that didn't appear to change anything, so now I'm wondering if the DebugBoolean -> AutoSmooth -> ConverToMesh (e.g. collapse boolean modifier) is somehow mucking things up? 

 Now working on the large window and despite the UVs all seeming to be in order, for some reason the cell fracture was still distorting the UVs at these corner points. I would suspect that it is likely this is due to those points being poles, but if so, why did this not happen before? ...regardless, setting the debug boolean, manually setting the auto smooth of each piece and then converting to a mesh appeared to solve the problem. Nevertheless, WTF. This process still seems to have some kinks I don't fully understand.

The 2nd floor window shutters definitely went smoother. One of the two still had UV issues that needed correcting. It's weird that only one wasn't entirely UVed...it was the same with the swinging saloon doors...weird.