Currently all of the custom-attribute types have to opt in to being an attribute in some specific way (e.g. the @propertyWrapper attribute), and that determines how they're interpreted. A single type can't opt in to being an attribute in multiple ways, so there's no technical ambiguity. Maybe we'll have to do that here when we generalize it beyond Sendable, so that protocols used this way can't be used directly as e.g. result builders or protocol wrappers. Although I really don't know why you would use a protocol for either of those in the first place, and indeed you would need some significant enhancements to protocols to even try.
I don't think it's a real problem that nothing about what interpretation a specific custom attribute has is obvious from the syntax alone — or at least, to the extent it's a real problem, it applies to attributes/modifiers/keywords in general, not just to custom attributes. Attribute names should be well-chosen so that a reader's first guess is close enough to not be wildly misleading.