Something I’ve been workin’ on. Coming soon™.
Essentially, the following objects would only work when parented to Part objects:
Now, they work when parented to Attachment objects, allowing developers to have more arbitrary control over how these objects interact.
To be honest… that is pure genius. What about SurfaceLights?
That’s!!! soooo!!! coooool!!!
SurfaceLights act exactly as SpotLights. They’re not really intended for use with this, though they can be used with this.
love that excited mouse moving in the video
Neat. Maybe the OP can use a little bit more body so less technically inclined / observant / informed people can understand what’s happening easier since this is in the announcement category
EDIT: 
Yyyyaaaaassss, this is going to be super useful. Thank you 
Any idea if it is possible to make Attachments work outside of parts too, like when parented directly to Workspace, Models, etc? (i.e. they would act as if they were adorned to a part at CFrame.new())
Terrain? Would still be nice to be able to parent to Models/Folders without it being a descendant of a BasePart
Oh, never thought of that, although a little arbitrary (but useful)
Certainly would be possible, but it would have to be proposed. This one gives me the feeling that it would get shot down. Just parent it to a part, and if push comes to shove have .2x.2x.2 anchored, transparent, non-collide part in the workspace at the origin and parent the attachment to that.
Would be sweet to be able to use attachments with joints like welds/motors as well.
Been wanting something like this for particles practically since they were added, so I’m definitely excited! 
Isn’t this the hack we’re trying to avoid by allowing parenting of these items to attachments?
Kind of, I guess? But it doesn’t make sense for the Attachment object to be parented to the Workspace. Model, maybe, but then it would just use the PrimaryPart of the model, so why not just put it there?
It would kinda make sense I guess if it would assume world coordinates if it’s not parented to a physical object, but that could be an issue if it’s in a folder that’s parented to- say a part.
If enough users are having to resort to a hack like that, isn’t it reason enough to make it a feature? I can’t think of another game engine where lights or sounds are tied to collidable/raycast-blocking objects, so it’s a little odd that these kinds of effects require them to begin with. Would be great if these effects just had a CFrame property of their own, didn’t affect in-game physical calculations, and appeared as a marker in-studio like attachments do e.g.
This has been suggested internally and shot down above my paygrade in favor of the Attachments ideas.
The looped death sound at the end hipnotised me