Sanity check? Or, nested phantom bom parts

TL;DR - Can nested phantom bom parts bork how phantoms populate boms?

I’m investigating a thing where a phantom bom component populates itself as a subassembly into a job bom instead of its components. There are other phantom bom parts in the same bom that are populating their components as expected. Yes, they’re all pull as assembly. Drilling all the way down to PartMtl, there are no differences in how each is configured. They’re added to the bom precisely identically yet somehow one of them does not act like the other ones.

The only difference I can find is that the misbehaving phantoms contain only phantom bom parts as components. Also configured as materials identically to working-as-expected phantom components. No labor, no actual material, just phantoms. I’m not judging on the philosophy of why someone would do such a thing, just suspicious that maybe the job bom populating code isn’t sophisticated enough to iteratively handle a bom that doesn’t have any real parts to chew on.

Are you doing this in one Get Details or are you going into Append Mode? I’ve seen phantoms not explode when in Append Mode.

Neither? It’s MRP making jobs from stock part revisions.

I’ve seen jobs where a phantom component which only contains phantom materials misbehaves like this, but a neighboring phantom component which contains any non-phantom materials does not.

It’s as though phantom bom parts require some corporeal component to summon them into a job’s material plane. Well, I guess it’s October so okay sure why not.

At this point I’m preparing some DMT to promote those phantom subcomponents up a level in all such boms. I can’t point to why, but don’t see any other difference.