The SpacecraftData class in the Parameter code is driven through a set of enumerated constants. That means that when a new component is added to GMAT that works like the existing tank and thruster classes, with new settings, the components need to be added to the SpacecraftData enumeration. Plugin components thus need to edit core code to add new thruster models if the Parameter code for those components are going to follow the existing implementation patterns. If they are to implement a different pattern, the Interpreter code needs modification, also an undesirable approach. The SpacecraftData code should be reworked to be more flexible.
Note: Thinking Systems is working on an approach to address this issue, so there may be a mechanism available for incorporation into the GMAT repository.