It was possible to render custom tags, with attributes, before custom tags support was added to the OE. The OE integration adds validation of parameters, and fails on undefined tags or attributes. In the current state, publishing will be blocked by the custom tags validator if such content is edited. This is a BC break.
In addition, we need to check how the OE reacts to such a case. We should also check how v1.0 reacted to that case: how were the tags displayed, and what could you do with them ?
It can be prevented by making custom tags validation opt-in. We can add an option to richtext that toggles the feature on/off, and make it disabled by default. Having it disabled should trigger a deprecation warning, and explain that having it disabled will be removed in the next major version.
Technically speaking, the parameter should be processed in a Container Extension, and disable validation at the lowest level, either by removing the injected service or replacing it with a null service.
An alternative is to handle this by decorating the validator and catching validation errors, and change them to warnings.
We could add an option, enabled by default, that ignores validation errors. If enabled, it decorates the validator (at container level), and changes the error to a deprecation notice, reminding that this behaviour will be removed in the next major version.
The minimum is that the OE doesn't crash when encountering an undefined tag, as it did not crash before we added the feature.
We may want to add a message on the tag's rendered view (in the OE) when this happens, and inform that the tag needs to be defined to be editable. Another option would be to guess the type of each attribute, but I think we would be overdoing it, as they were not editable before.