> It's not a "property" it's an attribute/field/member/key/column/variable/getter/function/procedure.

For what it's worth, to a researcher in the field of programming languages (like the author of the post), these all have distinct unambiguous meanings. At least as far as PL goes, almost every term has a well-defined meaning, but as those terms were adopted into less-than-academic contexts, the meanings have diluted.

"Property" is such a term in the context of programming languages research, and, in particular, it is a very specifically defined term in the realm of property-based testing (no surprise).

> Even the constants are variables from the viewpoint of the CPU that has to load it in its registers.

No; this is not what "variable" means. Registers are properties of the processor, i.e., they are implementation details; variables are an abstract concept from the domain of the formal language specification.

> Sometime along the way we decided that "syntax sugar" means "it means the same thing as" but except for (<cast OtherType>obj).foo(), which means that the semantics of "syntax sugar" don't mean it's simpler than the phrase it was supposed to replace.

No; this is not what "syntax sugar" means. If a language defines some syntax f and it "expands to" some other syntax g, then f is syntax sugar for g. This is well defined in Felleisen's "On the Expressive Power of Programming Languages" [0]. For example, Python's addition operator `+` is implemented in terms of a method `__add__`; therefore, `a + b` is syntax sugar for `a.__add__(b)`, because the former syntax is built on top of the latter.

Notably, syntax sugar has nothing to do with casts; casts are semantic, not syntactic. There are also no promises about whether syntax sugar makes something "easier"; it's simply the ability to syntactically express something in multiple ways.

[0] direct PDF: https://www2.ccs.neu.edu/racket/pubs/scp91-felleisen.pdf