While I think it's valid to discuss this, it strikes me as something that ought to be low priority. There are much worse design issues to tend to elsewhere, and AFAIK this task is not a prerequisite for any user visible improvements. I have the impression this is being pushed due to personal interest rather than what makes sense for the team/project as a whole. If anyone disagrees with that, this is fine. I'm providing _my_ impression in the hope it is helpful.

I already commented on this at https://github.com/wmde/WikibaseDataModelSerialization/pull/197#issuecomment-198025401, amongst other places.

I would be interested how exactly this is blocking T118860. I assume this is not a hard blocker.

What "worse design issues"? What "personal" interest? Please qualify these statements.

This issue is not exclusive to (De)Serializers, the same happens in ValueFormatters, Parsers, Validators and some more: an interface that does not say anything but that a method with a name exists. It does not say anything about what goes in, and nothing about what comes out. This triggers type safety warnings in all kinds of tools. People see this, try to fix what they think is a design smell and either fail (and wasted their time) or work around the issue by simply type hinting against package private classes. This alone is, in my opinion, reason enough to discuss this. When the outcome of the discussion is that we keep the interfaces untouched, but we all have a better understanding of the situation, fine.

I don't understand your comment https://github.com/wmde/WikibaseDataModelSerialization/pull/197#issuecomment-198025401, what you are aiming for and what your suggestions are. But as I did not got a response for a month I suggested to use an other discussion format.