Specifically, suppose somebody wants to obtain the pressure (for a given height), height (for a given pressure), density, altimeter setting for a particular locale, or the like. They should ask the atmosphere module to provide it. Similarly, if somebody wants to change something -- e.g. to cause a change in the local altimeter setting -- they should ask the atmosphere module to do it.
To say it the other way, it doesn't make much sense for the altimeter code to have one model of the atmosphere, and the ATIS code to have another model, and the gui to make changes based on its own model, et cetera. It doesn't make much sense to be exporting low-level properties such as sea-level-pressure via the native controls interface; such low-level properties should be private to the atmosphere model module, since they might not even mean anything, depending on implementation details.
It doesn't make sense to allow the user to have control of the temperature profile (as a function of height) while having independent control of the altimeter setting (as a function of height). Almost all settings that could be accomplished with this popup would contravene the laws of physics.
Somebody needs to first design a module to represent the atmosphere, and then -- only then -- design a user interface to match.
But if we allow one user to make choices that affect the atmosphere model, what happens to the other players in the vicinity?
Moving one notch up the totem pole, another option would be to implement a strict Kollsman model. That is congruent to the ISA model, plus an overall rigid shift up or down. This is a one-parameter model. (It appears that some of the current code tacitly assumes such a model, to the extent that any consistent set of assumptions can be inferred at all.)
The next step up would be a two-parameter model. The conventional choice would be for one parameter to be the Kollsman-style height shift, and the other to be a temperature shift that makes the atmosphere warmer or colder everywhere by the same amount. This would necessarily create a nonstandard lapse rate, in accordance with the laws of physics.
At some point we come to a model that can handle multiple layers. Just as the ISA has multiple layers -- of which the entire troposphere is just the first layer -- one could imagine multiple layers within the troposphere, each with its own lapse rate. This would allow modelling of rather complex phenomena, including inversions.
It should go without saying that within each layer, the various properties (temperature, density, pressure, etc.) should be mutually consistent, in accordance with the laws of physics. The conventional way of arranging this is to specify the lapse rate within the layer, treating that as the independent variable, computing everything else as dependent variables.
The preliminary jsd recommendation is to create a three-layer model (the troposphere and the lower parts of the stratosphere), and to have two free parameters (tropo height offset and tropo temperature offset), but to structure the code so as to make it possible to add more layers and then perhaps fiddle with the lapse rate in each layer.
Right now the winds-aloft model is independent of the atmospheric pressure model. This is inconsistent with the laws of physics ... although it is not the sort of thing that most pilots would notice.
If you want to go whole hog, you can implement a full-blown 3D computational-fluid-dynamics model of the atmosphere. This is probably not worth the trouble, and not a good place to start.