I see your point that nested serializers should actually be serialized as json value. The only thing I am a bit worried about when implementing this is backwards compatibility. If someone uses nested serializer though I guess it would only work with ModelSerializer with the current implementation.

So an implementation could be that nested model serializer continue to be serialized as relations but a deprecation warning will be printed that ResourceRelatedField should be used.
All other serializers can then render to a json value.

This is just an idea but open for discussion and PRs.

As a side note currently when using using JSONField it is possible to contain any JSON value in attribute which might be used as a workaround till a fix has been developed for this issue.

Actually it is possible to implement two strategies and configure which one to be used in settings:
The first strategy is to leave it as it works now, and the second is to serialize any nested serializer as an attribute.

For now, the first strategy would be set as default with a deprecation warning, and we will change this behavior in the future releases.

Or we can think about a mechanism to specify how to treat each nested serializer separately which is even more flexible.

I like your first idea with a strategy setting. This way the deprecation warning can warn new users which might think nested serializer serialize to json and what they need to do if they want to. And for old users it shows them that they should adjust their code to use ResourceRelatedField.