Can we break down your questions?

"facade shape optimization", e.g. a genetic algorithm selecting (an) optimal combination(s) of facade geometry (shape?) parameters (e.g. floor-to-floor height, WWR, surface azimuth/tilt, external shading design), against a given set of metrics (e.g. source GHG, peak summer kW, daylighting/glare). At each iteration (e.g. deployed as an OpenStudio SDK-based Ruby script):

1. facade shape parameters are permutated
2. EMS program parameters may be reset (see "EMS for facade control")
3. an IDF or OSM is automatically re-generated (or a template file is altered)
4. E+ simulation is automatically launched
5. followed by an automated results analysis

"EMS for facade control", e.g. some (not all) "facade" variables (e.g. external shading, thermochromic finishes) may be dynamically reset (actuated) during an E+ simulation, based on selected (sensed) variables (e.g. irradiance, illuminance).

"Include shape variables during EMS control", e.g. the EMS program may also depend on key facade geometry parameters (e.g. WWR, external shading design), i.e. inputs set in iteration Step 2.

The above is a coarse description of a (plausible) sandbox within which you may be operating. If true, I don't foresee any obstacles in setting "shape variables" (e.g. WWR) as EMS inputs at iteration Step 2. If one acquires the scripting know-how to reset a model's WWR, the same skills can be harnessed to reset a model's EMS (input) parameters.

I may be misunderstanding the questions. It would not be possible, for instance, to dynamically actuate a "shape variable" at run-time (via EMS). Hope this helps.