a "not-beaconable" flag on assemblers, labs, drills, etc

[Honktown]

A problem has come up for modders sometimes, where they want to use special modules restricted to miners or labs. At present, mods can detect many behaviors like player insertion, bots being requested to put in modules, etc. The one case where it is incredibly difficult / almost impossible / reasonably impossible is beacons + entity + module

Alternate methods can involve modifying effects across the board, so the modules have really bad effects applied to the "wrong" entities...

An idea is to have "not-beaconable" as an entity-flag. I imagine a beacon + effect receiving is only triggered in limited circumstances (placement, module changes, recipe changes, etc). In the purest case of becoming an effect receiver, it would seem to only happen on placing the beacon, or placing the entity.

Relevant to miners and labs, this means *in conjunction with other events and detection*, a mod can reliably detect all forms of an entity being modified by modules, without needing to have side effects [or a excessive number of invasive side-effects].

Alone, this translates to a completely independent set of modules for recipes, when applied to crafting. If someone wanted a specific recipe to only have module(s)-foo work on it [but not overly so], the only conditions are: can the crafter receive the effects and module apply to the recipe.

Edit: small changes after thinking it over

[curiosity]

I don't see the connection. A "not-beaconable" flag doesn't make it harder or easier to detect beacon effects (which you can already do by detecting changes to a beacon's modules the same way you described for other entities and find_entities_filtered to look for exisitng beacons), it just modifies behavior, which has nothing at all to do with detection.
This request sounds like it would be better served by allowing prototypes to limit module categories they accept or allowing modules to limit entities they are applied to.