Problem/Motivation
The changes in content_moderation/translation and how it handles non-translatable fields broke paragraphs pretty badly. See #2951436: Fix integration with content moderation in multi-lingual scenarios, based on some reports we saw, it also affects non content-moderation workflows (as in, non-workflow workflows. Excuse the bad wordplay, it is late).
The thing with paragraphs is that we display references entities, which have their own revisions and translations in the same form. The field itself is untranslatable (at least that's currently the only supported mode), and we lock down all changes that would result in a change on the field itself, to make sure referenced paragraph id/revision id and order can not change across translations. But we do allow the change the corresponding translations and revisions in the referenced paragraphs and their fields.
A lot of that keeping-in-sync stuff happens directly in Entity Reference Revisions which supports the concept of "composite entities" that only exist in the context of a parent and automatically get a new revision if the parent does.
That means we're technically compatible with the limitations that core has on non-translatable fields, the logic in content_translation/entity storage just doesn't know about it because all it knows is the isTranslatable() flag on the field.
Proposed resolution
There are a few steps that are necessary here to make things work:
* First we need to get around the fact that \Drupal\content_translation\ContentTranslationHandler::entityFormSharedElements() is hiding our widget on the form. I found a workaround for that, but I think it would be easier if widgets could just set #multilingual themself and content_translation_form_alter() would not override it. This might also help with some hacks we have right now to get rid of the translatability clue message.
* Then we need to prevent the field from being replaced with the default revision/translation values in \Drupal\Core\Entity\ContentEntityStorageBase::createRevision(). Not sure about this, maybe allow to extend the $skipped_field_names somehow or a hook that allows us to at least somehow undo things.
* While we don't want the paragraph field values to be replaced, we basically need to be able to apply the same/similar logic to our referenced entities. So when a new "merge-revision" of the node is created, we want to do the same to the paragraphs, so that they too merge their translatable/untranslatable fields together. And later on when we have fancy conflict resolution that will replace this special case, we'll need to be able to apply that recursively as well.