ASPxHtmlEditor - List items (li) disappear from content pasted from Word in Merged formatting mode after switching to HTML view and back to Design

The fix has resolved the original problem - li elements no longer disappear when switching between views for me. However, now, with the hotfix applied, the same inserted content from the same Word document gets deleted along with the empty paragraph I'm trying to put it into. I've attached a video demonstrating what happens. This seems to be specific to the Merge paste mode and does not happen with other modes. Also, I have not seen this before, so I think this is caused by the changes you've made to the pasting algorithm in the patch. Unfortunately, I have not been unable to create a standalone sample for this prolem yet - this seems to be specific to my app. Note that I have commented out my ASPxHtmlEditor customizations from my https://www.devexpress.com/Support/Center/Question/Details/T263833 and https://www.devexpress.com/Support/Center/Question/Details/T263850 cases when reproducing this, so this should not be related to them. The only use case when I managed to paste the content from Word in the Merged mode successfully is when the editor was totally empty (and no tags displayed in the Tag Inspector panel). Maybe you'll be able to figure out what code changes may cause this, or at least tell me where to look?
Also, I've noticed that the generated markup is very redundant and hard to maintain (not sure whether it was like that before). Here is what it looks like when I paste the sample Word document to an empty HTML file which has a style applied to its body:
Here's the body style:
body
{
   font-family: "Helvetica Neue", "Lucida Grande", "Segoe UI", Arial, Helvetica, Verdana, sans-serif;
   margin: 0px;
   padding: 8px;
   color: #696969;
   text-align: justify;
}
Here's the markup I get:
<p style="margin: 18pt 0cm 2pt; color: #000000; font-size: 14.6667px; font-family: Calibri, sans-serif;">
 <span style="font-family: 'Helvetica Neue', 'Lucida Grande', 'Segoe UI', Arial, Helvetica, Verdana, sans-serif;">
   <span style="font-size: 16px;">
     <b>
       <span style="line-height: 107%; color: #0079c2;">
         Test
       </span>
     </b>
   </span>
 </span>
</p>
<p style="color: #000000; font-size: 14.6667px; font-family: Calibri, sans-serif; margin: 0px 0px 10.6667px;">
 <span style="font-family: 'Helvetica Neue', 'Lucida Grande', 'Segoe UI', Arial, Helvetica, Verdana, sans-serif;">
   <span style="font-size: 16px;">
     Test:
   </span>
 </span>
</p>
<ul style="margin: 0px; color: #000000; font-family: 'Times New Roman';" type="disc">
 <li>
   <span style="font-family: 'Helvetica Neue', 'Lucida Grande', 'Segoe UI', Arial, Helvetica, Verdana, sans-serif;">
     <span style="font-size: 16px;">
       <b>
         Test
       </b>
       -
       <i>
         test
       </i>
       .
     </span>
   </span>
 </li>
   <li>
   <span style="font-family: 'Helvetica Neue', 'Lucida Grande', 'Segoe UI', Arial, Helvetica, Verdana, sans-serif;">
     <span style="font-size: 16px;">
       <b>
         Test
       </b>
       -
       <u>
         test
       </u>
       .
     </span>
   </span>
 </li>
</ul>
<p style="color: #000000; font-size: 14.6667px; font-family: Calibri, sans-serif; margin: 0px 0px 10.6667px;">
 <span style="font-family: 'Helvetica Neue', 'Lucida Grande', 'Segoe UI', Arial, Helvetica, Verdana, sans-serif;">
   <span style="font-size: 16px;">
     Test.
   </span>
 </span>
</p>
Here is the markup I would expect for the first paragraph:
<p style="margin: 18pt 0cm 2pt; font-size: 16px; line-height: 107%; color: #0079c2;">
   <b>
       Test
   </b>
</p>
The recommended changes are:

1. No duplicated font-family overloads - why keep the Word font-family and then override it with the body font-family, if you can just remove the font-family at all - the result will be the same?
2. No spans embedded into the <p> and <b> tags. Why do that if you can apply merged styles to the <p>, <li> and <b> tags directly?
3. No duplicated overloads for font-size and color (again, why double-overload it?). And maybe no font-size at all if it's the default font-size of the Word document.
4. Maybe no margins or line-height if it's the default values defined for the entire Word document.
   The same can be applied to ul / li and other tags. And an additional item for ul:
5. I would not expect it to have the color: #000000 rule. This is the default color defined for the Word document and it should not persist, the body color should be used instead. I think you know how to figure out which styles are default for Word docs, because your Rich Edit Document Server knows how to do that. Not sure whether this can be applied to clipboard data, though. Even if's not applicable to clipboard, you can still figure out the data comes form Word (based on Word-specific stuff in the Word-generated HTML) and just hard-code the Word default values (the margins, the font color, font families, etc.) in your paste processing logic.
   I realize this is probably the expected behavior and yes, I know I can use the client-side event to adjust the pasted content myself (that's not going to be easy, though), but don't you think ASPxHtmlEditor will benefit from generating cleaner markup out-of-box? Yesterday, I sent a lengthy document via email to Vladimir from DX support team. Please show this comment to him and tell him it's a good example of what I was talking about in regards to pasted content in ASPxHtmlEditor. This redundant markup will become a nightmare if you decide to change the styles in a centralized manner after some editing.
   Also, please let him know this case is another example of a hotfix which breaks something which was not broken before.
   Nickolay, Software Architect
   ClickHelp - Online Documentation Tool
   http://clickhelp.co

Yes, and I'm still on Chrome 45, if that matters.

Hello Nickolay,

To process your recent post more efficiently, I created a separate ticket on your behalf: T296118: ASPxHtmlEditor - Text is not pasted from Word in Merged formatting mode. This ticket is currently in our processing queue. Our team will address it as soon as we have any updates.