I’m going to leave the issues related to axes flags for later, after we finish making, demoing and documenting.
“…what negative values are supposed to mean.”
...is a darn good question that starts us on a path to an extreme answer.;)
In a final composition, transparent space can come and go. Users have the final say as to whether a counter, or inter-glyph space exists or not, as well as how big it is. With variable fonts, for the first time, the internal white space of the letters, the counters... alone... are variable.
Unlike a final print or web composition, where the counter or inter glyph space that's gone, is black, or zero, so to speak, in composing variable fonts, and with overlapping contours, the underlying counter may still exist, as indicated by it's negative number, meaning that counter has flipped.
On operability, while xtra is intended as a hidden axis, programs, or curious users could explore it for all sorts of operability, but first, the selection of the value is an operability leverage point. Being from the same sample in all instances of the axis seems like a reasonable minimum assumption, as this is what ytuc, and ytlc are based on, and no one in their typographic mind changes what in particular they measure, once they start measuring something in particular.
So regardless of what value is chosen as long as it's consistently measured, the xtra axis represents a range of transparent counter values on an axis where nothing else is changing. Also, like any other variation axis, every instance in the entire design space now has an xtra value, and its xtra can be micro-adjusted without damaging the typography. What that gives the variable font is a new thing, from this axis. E.G. change to the tracking/letter spacing, at any instance being used from the variable font, can now share that additional space between the xtra axis and the space being added.
That's a minor interoperability that lots of applications could hook into today, and it's based on not knowing what the value system means beyond relative per mille per axes. Super-interopability is possible when the same value is chosen across variable families, or anytime the same value, like the counter of the H of a non-variable font, can be added to an interested program.
I'll also add, that in the design phase, it was long practiced that the counters of every glyph were recorded on the drawings, and used to drive the suggested range of side bearings in the final type. We can do better with letter by letter xtra adjustments, but I think perhaps that's a generation of apps in the future. For now, this axis value is a summary, but like all the others, every glyph that has a counter, potentially has its own xtra, and every glyph that doesn't have any counter, doesn't have any xtra, which i think a lot of people have figured out, is important in and of itself.
Hope that helps, thanks for the great questions.