Guarding against infinite loops and other poorly-designed machines

Consider this terrible machine:

<scxml xmlns="http://www.w3.org/2005/07/scxml" version="1.0">
  <state id="a">
    <onentry><raise event="e"/></onentry>
    <transition event="e" target="a1" />
    <state id="a1"/>
  </state>
</scxml>

Because the transition defaults to external, the interpreter exits state 'a' and re-enters it each time the transition runs. This causes a new event to be placed on the internal queue. As a result, the mainEventLoop gets stuck in the "while running and not stable" internal queue processing.

My own implementation happens to place a counter on this loop: "while running and not stable and iterations < MAX_ITERATIONS".

Is it the official position of the group that there are a variety of ways to write a dumb state machine, and neither the standard algorithm nor the validity constraints will attempt to prevent them?

Having written it, this seems like a question with an obvious answer. Of course we aren't going to guard against someone writing <script>while(true) explode()</script>

However, the "valid value" for the "target" attribute of transitions, along with section 3.11, already go to some lengths to explicitly declare as invalid any set of targets that would put the machine in an invalid configuration. If we are not going to guard against one form of broken/silly state machine, why do we try to guard against another? Is it considered more acceptable to have an interpreter that may hang (given a broken input) versus an interpreter that enters an illegal configuration (given a different broken input)?