Further discussion revealed that, not only does Flexbox have the problem that its justify/align-* properties aren't necessarily tied to the logical directions (which makes the start/end/before/after keywords somewhat awkward). So, some favored the start/start/end/end solution better. Even worse, though, the flexbox's direction can be such that the “main-start” of the flexbox (flex-direction-relative) is actually the “logical-end” side of the Flexbox, so using start/end at all can be confusing.
As such, it was resolved to introduce special flex-direction-relative keywords for flexbox. The properties in question now accept flex-start/end as keywords.
The Box Alignment spec will define that flex-start/end map to start/head or end/foot on non-flexboxes, and define start/end/head/foot as properly logical.
The alignment properties are divided into two dimensions, one for each flow-relative dimension. In order to have terms for all four sides of a box, the terminology used in each dimension is different: the inline dimension uses start/end, while the stacking dimension uses before/after. (But see open issue on renaming before/after.) Right now the layout specs proposing new alignment properties use start/end keywords in both dimensions.
Note: Flexbox will be the first spec to go to CR with logical keywords.
Should alignment properties use flow-relative terms, or use start/end in both dimensions?
The proposal is to have the Box Alignment proposal's '-align' properties, which align in the stacking dimension, to use block-relative directions, not start/end (which are the inline-relative terms).