At the moment XmlText and RichText behaviour with various access cases with rendering embedded content is lacking in both user and developer experience.
Requirements for both field types (read "content that can't be viewed" as deleted, trashed or not accessible by the user):

1. As a visitor, I expect not to get an error page when I view an embed of a content I can't view
2. As a visitor, I expect to get a nice display when I view an embed of a content I can't view
3. As a developer, I expect a message to be logged when I view an embed of a content I can't view
4. As a developer, I expect an informative message to be rendered when I view an embed of a content I can't view
5. As a developer, I expect display to be nice when previewing an embed of content anonymous does not have permissions for
6. As a developer, I want to customise what is rendered when viewing an embed of content the visitor can't view

RichText status

Most of the requirements mentioned above are already implemented for RichText. What is lacking is:

1. Checking if content is trashed
2. Ability to customise rendering of a content that is deleted or trashed

XmlText status

XmlText lacks more of the requirements from above:

1. It will throw an error when content is not accessible by the user (consequently no logging either)
2. No customisation possible at all, if error is not thrown for a content that can't be embedded it simply won't be rendered

Approach

RichText's implementation is almost complete. It uses MVC implementation of field type's Renderer interface, also it uses templates for rendering embeds: content/location + block/inline + allowed/denied (as mentioned deleted/trashed is missing). Therefore it makes sense to finish it first and then handle XmlText, which can be based (with some refactoring) on RichText's Renderer implementation. Doing so would avoid repeating virtually same code and would allow reusing existing implementation that is already tested.

In contrast to RichText, which handles block level <div> wrappers through templates, XmlText handles it in XSL. One step before XmlText is handled through RichText base is refactoring it to be in-line with RichText in that regard.