The casing restriction does feel a bit at odds with the rest of the language design, where we so far have avoided making distinctions about identifiers based on case or other identifier characteristics. Case is also a Western script centric concept; is 懒 or كسول a valid property delegate name?
To keep user-defined attributes separated from future expansion of compiler builtin attributes, it would make sense to me to say that the builtin attributes live in the Swift standard library module, and allow user-defined attributes to shadow them, like other identifiers work today. You could then write @Swift.futureBuiltinAttribute to use an attribute we add as a language builtin in the future.