MarkupInterface interoperability with other PHP frameworks
TLDR

(this summarizes conclusions from the comments below)

The MarkupInterface is available on packagist as part of the drupal/core-render package, which provides all the classes from Drupal\Component\Render\* without any heavy dependencies (only drupal/core-util). It does not give you TranslatableMarkup, though.

If you let your package depend on drupal/core-render, you can use MarkupInterface as a return type.

Implementations within Drupal modules, which call t() and return a TranslatableMarkup object, would satisfy the return type from the interface.

Implementations outside of Drupal would instead return FormattableMarkup, or HtmlEscapedText, or a custom implementation of MarkupInterface. Or something else, if the interface allows alternative return types (e.g. native string).

You need to decide if you accept this dependency, or do something else instead.

Original (longer) answer

The ultimate goal of having the two names spaces in Drupal is


Drupal\Component is for classes that do not need a bootstrapped kernel.  In other words, these do not need a running Drupal system. These classes may depend on other classes outside Drupal\Component (eg, Symfony) or other classes in Drupal\Component, but not Drupal\Core
Drupal\Core is for classes that require a bootstrapped kernel.  These full from Drupal\Core, Drupal\Component, and elsewhere.


Take date/time objects.


DrupalDateTime is in Drupal\Core because leverages the translation service.
DateTimePlus is inDrupal\Componentbecause it adds some enhancements to the native\DateTime` class.


So, in theory, Drupal\Component can be used in anything. That said, the composer.json files for each component may not be accurate for dependencies and minimum PHP version.

In your case, MarkupInterface and FormattableMarkup should be able to be used outside of Drupal. TranslatableMarkup relies on the Drupal translation system, which needs a booted kernel to operate.

TranslatableMarkup essentially just extends FormattableMarkup, and acts a bridge to the string translation service. So, that on its own doesn't buy you much unless you need everything that surrounds translation (language management, the UI, etc).

All of that said, I am not sure how much you will really gain from this. Ignoring the translation parts, FormattableMarkup is a component, but they are really best used as part of the rendering service, which is part of core.  For the purposes of making your own API, I would start with seeing if you can just leverage FormattableMarkup on its own.