...
A better answer to this question might have stepped back and considered - at what level does Infusion actually solve problems like this at all? And whilst there is some small assistance for dealing with these in-place issues where they occur in fine-grained elements such as free-form component options or model material, these problems are in practice only solved at the level of entire components. This implies that a more appropriate solution would be to upgrade the leaflet "Map" into a "mapHolder" component of its own, whose only purpose was to bear constructional responsibility for it. Which of course is what hortis.leafletMap originally was, before it got larded with additional design responsibility. We could then have shifted the workflow into the "onCreate" of that component.
This still raises issues as before - we are forced to create further, and more fine-grained design elements than was our original design taste, when these so-called "unforeseen" refactoring challenges arise. A lot of our taste for component granularity is based on efficiency considerations - until we have the FLUID-5304 "Infusion compiler" the run-time costs of extra components are really egregious, but also just at the design level incurring 3 extra levels of nesting in the JSON structure represents an annoying readability constraint.
...
All this raises rather deep philosophical issues about what it means for a value to be "fully evaluated", especially if that value classically appears to be a container for other values. This clearly has a different meaning depending on the nature of the consumer. If this consumer is a classical function, it naturally expects it to be in the classical sense, and indeed we have a JIRA about this too - FLUID-5981. But if the consumer of the value is the framework's own machinery, the answer is clearly different, otherwise no variety of "retrunking" could be supported. This directly feeds into the "containment without dependency" notion [footnote - first cited in PPIG 2015 paper at https://github.com/amb26/papers/tree/master/ppig-2015, this is the central insight of the 2010 Pupusa Queue Conversation] notion that founded the entire framework. From an OO or FP view of a structure, the structure "depends on" its members, and from our point of view it doesn't.
So - are we "changing" a trunk value (object or hash) by "discovering" further members nested within it during our evaluation process? In our particular riff on the notion of "referential transparency", we are not - since to us, a reference is an address. Having noted that we know what the type of the "value" is, and what its address is, we have noted two unchangeable facts about it - these do not alter during the evaluation process for the "value", nor for any other values that are found to be "nested" within it.
But to return to the theme at the head of the page, implementing such a process of "discovery" in a conventional programming language leads our "functions" to have a very peculiar appearance, and also a rather stereotypical one - they necessarily must accept some kind of more or less massive "environment" as an argument, in order that they may deliver a freshly discovered value "in-place" into its appropriate spatial position at the very earliest possible moment. In terms of the base programming language, this is a huge weakness - the function as well as being massively impure, has a massive environmental dependency that greatly restricts its reuse. It is for this reason that taking the hit of "being an Infusion" is something that we want to incur as rarely as possible, despite our commitment to pluralities in Infusions.
Let's now survey what these sites actually look like within Infusion, starting at the small scale where individual options values are "delivered":