Regarding this change: https://android-review.googlesource.com/c/platform/frameworks/support/+/1435797 is there a specific reason to let the drawing order affect the zOrder instead of an expliciet (and optional) zIndex parameter to the place* methods? When code in a custom layout is re-ordered (for whatever reason) this potentially breaks the layout. Or am I missing something here?

Funny you should ask, your questions mirror an ongoing discussion about exactly that 🙂

Ok, thanks for the update. zIndex as a parameter seems like a good addition if one wants to be explicit about the zIndex when adding composables.

When code in a custom layout is re-ordered (for whatever reason) this potentially breaks the layout.

This seems like a good thing to me, generally. It's intuitive that composables' z order is related to their order in code, since most view systems work this way. If you have a custom layout that depends on the ordering of composables and the directly children of that layout aren't an implementation detail of the layout itself, that would be brittle regardless of how z-order is determined, and probably using custom modifiers that set parent data is both a more readable and more robust way to identify children to the layout.

Yeah we're thinking of a few different potential angles; the current system, one where Layout Modifiers could augment the Z coordinate just like

Modifier.offset

does, or one where it's expressed as parent data and is only available from layouts that choose to support it