I would also tend to agree that this set of rules is a bit arbitrary and seems a bit like some overfitted classifier in pattern recognition (although there were worse sets or rules in that regard).
Jugding from the numerous failed, awkward or too specific attempts to define such a set of rules, maybe it would be better to admit that there is no clear, boolean rule possible. Instead we could define a set of measurements against which each keyword is weighted empirically to choose the optimal form (attribute/keyword) on a case-by-case basis. Such rules could be for example: - needed changes when porting from C/C++ - frequency of use - @ is quite disrupting, both, in terms of typing and reading - if it changes the syntax used for accessing the annotated entity it probably should not be an attribute (e.g. property or type constructors) - interference with user code - how likely is it to get name clashes with user variable/function names Obviously there would some disagreement for the third rule - I am definitely for property as a keyword - but that aside, I think this approach would prevent us from pretending something which is not there and also does not lead to possibly silly forced desicions for future keywords. Sönke
