See https://github.com/mathml-refresh/mathml/issues/50#issuecomment-508737052

Consensus during mathml core meeting: Ignore width/height on all new layout as they are no clear use case and that simplifies implementation. It still makes sense for mtable or math elements.

You still need to define this for nested elements which do abide by width/height. (See test-case).

Update: although my answer below touches on this issue, I think it is more relevant for w3c/mathml#50 since token elements are mostly (currently) defined as block level elements in the spec.

For leaf content, it seems that the answer lies in whether we decide leaves are inline or inline-block. If inline, then this question is trivially resolved (it's 0). Currently the core spec says that mtext (and hence many leaf elements) for layout are block box. Assuming this stays, then it seems like the width needs to be relative to a parent context that can set the width: either math or mtable. In the latter case, if it lies in a column of fixed with, then that's the context.

The issue of whether elements are block or inline has come up a number of times. My memory is that in most (all?) cases, having most elements be inline simplifies interactions with CSS. Although @fred-wang is probably not happy with opening up something he probably feels has to be the way the spec says it is, we probably should have an issue to at least get the rationale down so everyone can understand it and agree upon it.

You still need to define this for nested elements which do abide by width/height. (See test-case).

Proposal: resolve percent against 0 in this case.

I am not sure that the original example is valid, according to the spec div is not allowed in span.
I did my experiments with:
https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=7193

Consensus from 2019/09/12 is essentially: use the size provided by a block container without display: math