The reason I did catch this later was a failing StrictMode ThreadPolicy. But a lint rule warning against with(CoroutineContext) seems like it'd be nice to have.

I'm curious how prevalent the onGloballyPositioned pattern is and why - does it feel like the best way to accomplish more custom layout behavior? Is it the easiest thing to get something working close enough? Are there missing tools that would make it less likely you'd use onGloballyPositioned?

This video from last year goes into a lot more detail about the problem space here, along with some examples of how to approach different problems:
www.youtube.com/watch?v=PUxt...

Unfortunately there's not really a one-size-fits-all solution for every case, but don't be afraid of a custom layout - if you're already doing some math to change the layout of something based on something else, you're about 80% of the way there to writing a custom layout.

This can also wreck havoc on animations - maybe they can cover up some of the jankiness, but animations need to have a consistent view of the layout as it animates at each point in time. Shared element transitions don't really work if the shared element disappears completely for a frame.

Nesting this approach makes the situation even worse - each time you put a calculation like this inside another one, it adds an additional frame required to resolve the whole layout.

When you have composition being driven by information that you can only get in a later phase, like measurement, layout or drawing, the first composition can't be correct!

This means that the first frame might be blank, or components might jump around as you get more info.

I smile every time I hear a voice assistant says "Panic! at the Disco" out loud when playing music, it dutifully pronounces the punctuation.

I really like "artisanal" as a descriptor, I think it's going to matter even more to be specific about expectations for types of code based on what it's for.

Would anyone really need an artisanal repro sample, or an artisanal one-time use script?

What about an artisanal library or sample?

And to reiterate again: configuration changes will happen, and you have to react to them. For each type of configuration change, your options are:
- using Activity recreation, and properly preserving state through it
- opting-out of recreation, and updating everything in place

Some are a lot trickier to handle directly - and it's pretty easy to write code that works assuming that recreation happens.

Opting out of recreation is also a promise that new code works properly with updating in-place when the configuration changes.

It's also not all or nothing! Most Android apps can probably opt-out of recreation for some configuration changes that don't need apps to do much (if anything), like keyboard, touchscreen, and colorMode.

That'd immediately solve a whole class of bugs for physical keyboards and connected displays.

TL;DR: if you know the promise you are making, you can opt-out of Activity recreation via android:configChanges.

The golden rule to do so properly in Compose is to have everything using configuration depend on a snapshot-state-backed source for it, like LocalConfiguration and LocalResources.

...and the source for my slides is here!
github.com/alexvanyo/al...

I built my talk with Compose itself, using @bnorm.dev's github.com/bnorm/storyb... project. Shared elements and transitions galore, directly using the Compose APIs for it.

Are you using the platform level drag and drop here, or something app-local?

Also - depending on jurisdiction, supporting multiple orientations can be an accessibility requirement, regardless of device type.

Prioritize accordingly based on what makes sense for your app and use cases - but users are absolutely using it across different form factors, window sizes and input types.