About the EnterKeyHandling.js changes in general:

I understand that `<br>` does not start a new block, and therefore leads to problems where multiple *logical* paragraphs are represented as just a bunch of text separated by `<br>` nodes.

This started with https://bugs.dojotoolkit.org/ticket/6187, where I included EnterKeyHandling in the Editor by default, and I set the default mode to BR rather than P.   In retrospect that was probably a mistake, as I [wrote in the ticket](https://bugs.dojotoolkit.org/ticket/6187#comment:9).  So, I think I'd be willing to switch the default blockNodeForEnter to "P".

Some things though with your patch that I don't want to check in:

1. if the user types shift-enter it means they explicitly want a `<br>`.  I'm not inclined to add an option / implicit behavior to turn off that functionality.

2. Likewise, I don't want the BidiSupport plugin to secretly change the EnterKeyHandling plugin from BR to DIV mode.   IMO It's too much magic.   You can of course document that the BidiSupport plugin is incompatible with EnterKeyHandling BR mode.

3. I'm unclear what the other code changes in your patch are for, but they need test cases.

So, you that leaves two similar options:

1. Submit an independent pull request with the changes you need to this file, assuming that the app sets blockNodeForEnter=P.

2. Submit an independent pull request as above, but changing the default blockNodeForEnter=P.

In either case you need automated tests to show what bugs you are fixing with the added code.