To clarify, you implied a bit earlier that the texture itself should also be able to be used to input transparency into the mesh:
This was the part I was referring to. Of course it is simple to revert the Transparency property, which isn’t personally my concern in terms of developer control; rather, my concern is that we can’t analyse textures for Transparency to catch those items out. In fact, one item on the catalog appears to seemingly use that exact trick to obtain its translucency rather than the Transparency property.
Translucency is just naturally more expensive to render since you still need to render and depth-sort any parts behind the object, too. I’d recommend checking out my reply in the other topic if you haven’t already since it goes into a bit more detail about why Roblox’s current approach for translucency makes this difficult to acheive without visual artifacts; these are long-standing implementation details which have unfortunately existed and stayed for years afaik.
This behaviour isn’t documented anywhere. Maybe it is intended, but in that case, we should ideally wait for a staff to confirm it.
This can impact developers’ experiences, even more around the fact that many developers don’t/didn’t even know that this was a potential concern to worry about! Translucency is still very much hacky on Roblox, and it very much shows with a lot of broken enough behaviour when used in many cases.