As you will always have some form of text rendering in the engine it's save to assume that while it might change, maybe even drastically, it is near impossible to be removed completely.
No, this is an incorrect assumption, and text rendering is actually a good example of why. I have been monitoring the canvas formatted text proposal, which lets the browser do the text layout for formatted text when rendering to a canvas. Currently we have had to implement our own custom text layout engine in JavaScript, which is both extremely difficult, has lots of difficult bugs and edge cases, and is reimplementing what the browser already does. Ideally we could switch the implementation to a browser-based one with the canvas formatted text proposal and delete our entire custom implementation. It could then have more features, better performance, better consistency, broader internationalization support, and so on.
However if we did that, all third-party addons which rely on hacking the internal text layout engine will be broken. All the internal text layout code would be deleted, so there is no more scope to modify it. It may then be impossible to achieve the same thing with the browser built-in feature, as from our point of view, we only need the new text engine to be compatible with the old official features. It is possible that third-party addon compatibility is then such a severe backwards compatibility problem that we have extreme difficulty implementing the new, better engine; or even we have to cancel the project to upgrade it. For us, that's game over: now we can't upgrade the engine, or it is far more difficult to do so, and so we end up stuck with inferior systems in the long term.
This type of thing can happen with literally any part of the engine. The undocumented features warning is there because we want the flexibility to be able to upgrade the engine in the long term. So really the problem here is developers assuming it is fine, when it is not. It is meant to be a serious warning that is taken literally. If you ignore the warning and assume it will be fine, and then everything breaks, we reserve the right to say "sorry, we warned you about this" and proceed anyway, to avoid the outcome that we are unable to continue making improvements long-term.
Do you want to support 3rd party development?
Obviously yes - if we didn't, there would be no addon SDK at all. Exposing a controlled public API is the industry standard, and as I keep saying, the only reason people can bypass that in Construct is because of weak encapsulation features in the JavaScript language.
Would it be possible to set up a way for folks to more easily get access to an expanded api?
I think perhaps a good way to do this would be to put the addon SDK behind the scripting interfaces used when doing JavaScript coding in Construct. That is already a more comprehensive, documented API, which does have encapsulation, and it avoids us needing to implement and document APIs twice (once for the SDK, once for scripting) - by adding an API there it then becomes available to both addon SDK developers and JavaScript coding simultaneously.
Again, you needn't promise eternal stability, just a way to get the job done
Yes, we do need to promise indefinite stability. Otherwise if we change it say 5 years down the line, it breaks a popular third-party addon, thousands of projects are broken, and the original addon developer has left the community, then we have a huge compatibility mess which we are left to deal with. This has happened. Again, this is a case of people assuming things will be fine, but it is not. The only way to avoid this is a public, documented API that we promise to support indefinitely.
Do actually believe that behavior alone addresses all needs within the genre in a scalable, and sensible way?
Maybe the behaviors don't do everything. They are designed to be flexible. But beyond that, you can use custom logic in event sheets, or JavaScript coding within a project, to implement things like custom movements. You don't have to jump to hacking the engine internals. There are usually several ways to get things done.