Model-Driven Mechanism (MDM) is the basic answer to the fundamental question how models work. It is also for metamodels–if you acknowledge that a metamodel is a model . Metamodel sets a range to discuss multiple model-driven mechanism (multi-MDM). Here, we can adopt a concise definition for metamodel from OMG’s MDA Guide Version 1.0.1, “A model of models.” Or more rigorously stated by Jean-Marie Favre (2004) : “A meta-model is a model of a set of models.”
One of the most significant contributions shown by MDM may be that metamodel at runtime. For making a metamodel evolutionary, according to the principles of MDM, a system must use the modeling knowledge of the metamodel, i.e., meta-metamodel in MDE context; in other words, this also forms an MDM structure in which the applied model is the modeling knowledge of a lower level MDM structure, both composes of a multiple MDM structure, see the figure below.
In the graph, there are two MDM structures overlapped , respectively in green and blue. The dashed-line arrows, Device (1) to Target Thing, Device (2) to Target Model (M2), represent the logic relationships, which can be reached in different ways, indirectly (as shown on the graph) or directly. For an application system, as mentioned in the last post, the division of module has a variety of options, for example, one may put all the code for the Device (1) and Device (2) in one program, or divided into different modules, such as modeler, model driver, and operator, etc., which are must be according to the logical relationships shown in the basic MDM structure. Just like as the basic MDM structure, multi-MDM has also significant universality, for example, DBMS and its applications .
Note that, as highlighted by the red horizontal line, the graph shows on the lowest level MDM which is to be used for the real word (or, the outside things of the system); thus the graph also shows that how the two MDM structures are served to connect the real world and abstract world , i.e. the concrete thing and the abstract thing operationally.
Furthermore, the multi-MDM can also be double (as shown in above figure), triple, and more.
 This is probably not always a simple question when one tries to adopt a precise definition to the concept of model. For the discussions about MDM, however, I would rather give up those doubtful kinds of “metamodel”, e.g., to call them another clear names, even though just for the simplicity of terminology. This is also an additional note about that why I did not use “metamodel” but “modeling knowledge” in the basic MDM structure (see here).
 Favre, Jean-Marie. “Foundations of model (driven)(reverse) engineering: Models-episode I: Stories of the fidus papyrus and of the solarus.” Language engineering for model-driven software development 04101 (2004).
 Here, one can be more clearly seen why the Target Thing and the Functions and Behaviors to be shown in the basic graph of MDM.
 Yu, Tong-Ying. “Model-Driven Applications: Using Model-Driven Mechanism to Bridge the Gap between Business and IT.” In Advances and Applications in Model-Driven Software Engineering. Díaz, V.G. et al. eds. IGI Global, August 2013 (in press, see Recent Work on Model-Driven Applications (MDApp))
 This is indeed a quite meaningful topic, and I have shown a good background for such the discussions, i.e., the three spaces: physical space, conceptual space, and computational space (see here and here).