If we decide that certain kinds of issue transmutations should be forbidden because of potential harmful effects they may cause, we'll need to decide how exactly to enforce that. It'll likely need to be done at runtime—for example either by ignoring the illegal modification and recording a secondary issue describing the violation, or perhaps by triggering a fatal error or something more severe.
Given that I plan to incorporate @x-sheep's suggestion and bypass sending .system issues through this interface, I think the practical concern may be less to begin with. In general, if there is a non-.system issue, it should be the result of some action the user took, so I'm not sure we should prohibit modifications of that class of issues.
Looking to the future, supposing we did implement something like a .memoryLimitReached issue kind (again, hypothetical for example purposes only), my sense is that any behavioral effects of such an issue should be limited to reporting only. An Issue isn't the same as an Event: if, in the future, we implement some new feature which has important observable downstream effects on the overall testing system, more than just recording that something happened for later analysis, then such a feature should probably be represented as a distinct Event kind, possibly in addition to an Issue kind. This proposal is only intended to allow reacting to Issues, not any arbitrary Event of which .issueRecorded is but one kind.