The short answer is that changes to a property aren't coalesced. The change notification is only a notification that something changed, and it leaves the getting and determining what's changed to the underlying code. As you've seen, a change notification handler can be called repeatedly, with apparently the same information inside it. When you can do to sort of work around this is make your own publisher from the messages that reacts to the change notification and sends the message down it's own pipeline, and include .removeDuplicates() as an operator on that pipeline, then. subscribe to it in your view with .onReceive to process the updates. This (obviously?) doesn't stop the duplicate notifications, and still triggers a send of the message value each time, but your pipeline with removeDuplicates does the coalescing for you, and you have a publisher that's providing you the specific values you want to work with - the message content.

I don't think that there's currently a way to explore and examine (programmatically) what is in the environment - so there's no obvious way to verify that the object you're expecting to be in the environment was injected. To deal with this little quirk, the pattern that I've seen used in some code is to have an top-level View that explicitly injects the relevant environment object, often as a an explicit parameter to that view, and then use that as a base point upon which you can assume (safely) that all subviews from here will have the relevant pieces you need.

First does send a completion when it's triggered, although I suspect for this use case what you want is actually firstWhere, which looks for a specific predicate to trigger on before sending values - where first just takes whatever it gets right off the bat (meaning you had to filter the content earlier in the pipeline). The difference is minimal - when used inline it just looks like a parameter to the first operator, but they're different structs under the covers. While I was working on a my own reference content for Combine, I wrote a bunch of tests that worked all the various operators, so if you're so inclined, you can see what I did there to test the first operator - it's open source.

I was hunting for something akin to this path myself, and haven't found any public accessors for RealityKit's entities to be loaded other than the loadModel, which in the examples are specific to USD formats. - https://developer.apple.com/documentation/realitykit/entity/stored_entities/loading_entities_from_a_file I suspect that in order to load your model in RealityKit, you'll first need to explicitly transform your STL-sourced model into USDZ, write it to a file or buffer, and then load it from there with loadModel - https://developer.apple.com/documentation/realitykit/entity/3244091-loadmodel or it's neighboring methods.

I found a hint to the answer on twitter - in case someone else comes looking here: You have to be targeting a device for even compilation to work correctly. Once I connected an iPad and targeted it directly, there wasn't an issue with the compilation. Would be awfully nice to have this as a note/warning in the sample code though

For what it's worth, I've also submitted this as feedback with a relevant screenshot showing the compiler output, as FB9013606