I've a few things I'm looking into before merging this:

• Ensuring that there are no problems with calling onSplit directly rather than restoreContentAndSplit. My current conclusion is that we don't need restoreContentAndSplit at all, and it's proposed to be removed in Rich Text: Remove restoreContentAndSplit #7618.
• Ensuring that there's no issue in not reaching the part of splitContent which considers context.paste. I'm still not entirely clear what it's responsible for doing, and am continue to explore further.

Updates:

• Rebased to resolve conflicts.
• Restored respect of the insertBlocksAfter potentially being undefined for a locked template. See also Block API: Change block mutation functions from undefined to noop in locked template #6587.
• Refactored RichText split once more: This time simplifying to handle edge detection at once, with a single path toward restoreContentAndSplit with handling of paste context. See extended commit message of 7a8ec43.

This pull request is part of a performance audit of the paragraph block. It seeks to resolve an issue where we needlessly call setAttributes on a paragraph block when splitting into a new paragraph.

I think we are stilling making a non required setAttributes call.

I added this paragraph as the content of the post:

<!-- wp:paragraph -->
<p>123456789</p>
<!-- /wp:paragraph -->

I opened redux dev tools in core/editor store.
I put the cursor between 5 and 6 and pressed enter.
I checked that we dispatched UPDATE_BLOCK_ATTRIBUTES with content equal to "123456789" (not needed). Then we inserted a block and then we updated the content of the original block.

It is possible to check that we are doing a non required UPDATE_BLOCK_ATTRIBUTES also by inserting many paragraphs without any content. To undo each paragraph creation we need to use undo two times.

@jorgefilipecosta Nice catch. I can reproduce this. However, I think it's a totally separate issue. Namely, we're causing UPDATE_BLOCK_ATTRIBUTES to be called because even though we're explicitly handling the split on enter press, the event binding for input will cause onChange to be called with the editor content. We should probably prevent this for the enter key (or when otherwise knowing that there is other explicit handling for the input).