Some thoughts:

There are multiple strategies for serializing/deserializing the tenant ID / entity ID pair. We could:

• use an exotic string as separator such as "__HSearch_tenant_id:" (and hope for the best)
• roll out our own escape/unescape mechanism (`org.apache.commons.lang3.text.translate.CharSequenceTranslator` could help, but this would sill be tricky)
• serialize the tenant ID / entity ID pair as a JSON array (this would not be

In any case, those strategies should only be used if multi-tenancy is enabled.

Using our own escape/unescape mechanism may result in more readable IDs (if we choose sufficiently exotic characters), but would also be more prone to bugs. We could use off-the-shelf algorithms, though, such as `org.apache.commons.lang3.text.translate.CharSequenceTranslator` (see examples like `org.apache.commons.lang3.StringEscapeUtils.ESCAPE_JAVA` and `org.apache.commons.lang3.StringEscapeUtils.UNESCAPE_JAVA`; it would probably be much simpler in our case), but still, transforming the concatenated string back to a pair of escaped strings won't be easy.

In the end, we may be better served by never trying to interpret the Elasticsearch document ID, and simply using the ID field that was added in a recent PR: https://github.com/hibernate/hibernate-search/pull/1192. That PR has not been merged yet, though.