Clarify the nested case of `contenteditable=true` and `contenteditable=plaintext-only`

There are 2 simple cases:

<div contenteditable="true">
  <div contenteditable="plaintext-only">plaintext-only</div>
</div>

<div contenteditable="plaintext-only">
  <div contenteditable="true">rich text allowed</div>
</div>

Perhaps, initial shipping of contenteditable=plaintext-only of Firefox may depend on the topmost editing host value (i.e., focused editing host) because there are complicated issues.

For example, in the following cases, it's unclear whether rich text or plaintext should be pasted.

<div contenteditable="true">
  [rich text
  <div contenteditable="plaintext-only">plaintext-only]</div>
</div>

<div contenteditable="true">
  <div contenteditable="plaintext-only">[plaintext-only</div>
  rich text]
</div>

It seems that Chrome considers it from anchor node of selection. So, if you make the above selections with opposite direction, you'll see different result.

Start by reviewing the two simple nested examples and the selections that cross editing hosts, then compare the reported Chrome behavior. Determine the expected paste behavior for each selection direction and document an agreed rule for the nested contenteditable case.