Summary of the problem:

I've ran into this issue in the past, and found one work around, but haven't seen a true solution to this.

In the attached assembly/screenshot, I have three parts, and two assembly hole features. One hole is an M3 through hole, and the other is an M3 tap drill hole. The feature scope of each hole is strictly limited to the single part in which the hole is meant for (i.e. the tap drill hole on the front-most part in the screenshot, and the through hole in the middle part). Before you ask, the reason I'm not using a Hole Series is because the assembly pattern wouldn't take it as an input for some reason (another bug?).

After doing a circular pattern of both these holes, the scope of the through hole on the middle part seems to be applied to all parts in the assembly even though the assembly hole feature governing this through hole has a limited scope of the middle part ONLY. In the screenshot, or if you open the attached assembly, you can see this original hole used for the pattern, and its through hole and tap drill hole remain correct, while the patterned holes do not.

I see this occur in assembly mirror features as well. I can regularly reproduce this and one workaround I've heard of so far is doing everything as a separate body extrusion, and combining everything through a subtraction of bodies later. For simpler parts this has worked for me in the past, and I even have such a schema in the larger assembly use by this one, but with an equation driven pattern as I have here, this would not work as the number of bodies would change, and thus I'd have rebuild errors every time I'd change the number of holes.

Another workaround that can work, is to set the M3 through hole end condition to go "up to surface" rather than "through all". I don't like referencing surfaces in assemblies like this though since sometimes the referenced surface will be missing after some upper level editing and a rebuild.

I guess the best workaround would be to drive the thicknesses of each part with an assembly level variable, so this is what I will do from now on, but I still feel this strange feature scope behavior should be addressed.

Question:

Why does the end condition of the holes change when patterned or mirrored? Is this a bug? Is there a better workaround than the three I've described above that allows for equation driven patterns and stable rebuilds?