I'm not sure how you'd get the "shared" LineStrings from your shapes. Secondly, once you reduce a "subset" of the shape since your endpoints may move from the original and you will not be able to make them match up after reduction.
The nutshell of what I would do is basically use boolean operations to play with the reduced shapes.
First, do what you do, namely create a temporary table of reduced shapes (called #ReducedShapes).
Then, I would create a second temp table and find the areas of overlap (using STIntersection) between all shapes. In this table, I would basically have columns naam1, naam2 and intsec, the last one being of type shape. Something like (untested):
INSERT INTO #IntSecs(naam1, naam2, intsec)
SELECT s1.naam, s2.naam, s1.naam.STIntersection(s2.naam)
FROM #ReducedShapes s1, #ReducedShapes s2
WHERE s1.naam.STIntersection(s2.naam) IS NOT NULL
This gets you a list of where pairs of shapes overlap. In fact, you have two rows for each overlap. For example, if A and B overlap you'd have and . I would make a pass and delete one of the two for each occurence.
Lastly, for each overlap, I would subtract (STDifference) the intersection from only one of the two regions in the pair from the #ReducedShapes table. Imagine you have two squares A and B, half-overlapping. The operation would involve A.STDifference(B) meaning you keep all of B and half of A. I would insert the modified shapes into a third table (say #ModifiedShapes).
Two problems:
a) as you can see from your "orange" and "blue" shapes, they did not reduce similarly, so you'll get one of two possible reductions depending on how you deal with who "wins".
b) a more complicated form of the problem is that, depending on the complexity of the initial shapes, you may get overlap between three or more regions. You'll have to determine your own way to establish which one shape "wins" in that intersection, based on your particular needs. It's not clear if there are constraints. Could be as simple as arbitrarily picking a winner by ordering, or more complicated since accuracy is important.
The above concept unfortunately does not address the issue of gaps. This one's a little more complicated and I am not 100% sure how to resolve it. But, if you create a third table that subtracts (STDifference again) all the modified shapes #ModifiedShapes from all the original shapes in #Shapes (testing for overlap before actually subtracting, of course), you'd be left with the remainder shapes in the gaps. You'd want to aggregate the adjoining shapes and assign a "winning color", possibly merging it back in with the related shape.
This answer is long and I will leave it like this. I may be barking up the wrong tree. Based on your feedback/questions, I would add to the post.