From a user perspective, will the new terms encourage the right mental model for when value types get flattened (or not)? As an EG, early on we spent a lot of time discussing "flattened" vs "flattenable" and trying to guide users to the view that this is a VM-level decision and not a guarantee. Does leaning on the "pass by value" inituition undo that previous work?
The intent of this taxonomy is indeed to encourage the correct mental models (now that we actually understand what the correct mental model is.)
The centerpiece of the current language design is that, for primitive classes, there are two ways to "describe" an instance: directly and indirectly. The varying modes of description applies (among others) to fields (flattening) and calling conventions (scalarization) and variables (does the variable hold a value, or a reference.) The intuition of "by value" and "by reference" is intended to capture all of these differences; do you store the value, or a reference to the value? Do you pass a value, or a reference to the value? Is the type of `t` a value, or a reference to a value?
As a statically typed language, we capture this distinction by dividing between _primitive value types_ and _primitive reference types_ (a form of reference type, an existing concept.) The modifiers "value" and "reference" are chosen to evoke "by value" and "by reference", whether for passing, storing, or describing. It took a long time to realize this was essentially a forced move, since the value set of interface types consists of references to objects, and if we want primitive objects to implement interfaces, then there must be a way to describe them with references as well as directly.
The reference vs value characterization is semantic, but reasonably correlates with expectations about runtime behavior. Today, with reference types, we assume that they will _routinely_ be implemented with pointers (and they are), but in some cases, the VM figures out it can scalarize or constant fold (and we don't mind). Similarly, with primitive value types, we assume they will be _routinely_ flattened, but the ultimate decision is the VMs, and there may be circumstances when the VM decides on an indirect representation. So these intuitions are aimed at setting reasonable expectations, but not guarantees.
