See https://fr.wikipedia.org/w/index.php?diff=107442976&oldid=107442557 for an example.
Cutting and pasting the table takes this line of wikitext:
! scope=col| Performance
and turns it into this mess:
! scope="col" | <nowiki> </nowiki>Performance
Version: unspecified
Severity: normal
Can't quite work out what's going wrong here; this feels like a Parsoid bug, but I can't pin it down. Don't suppose this looks familiar to them?
Seems like on cut-paste, the contents of the <th> are being wrapped in a p-wrapper.
<th scope="col"> <p>Épreuve</p></th>
<th scope="col"> <p>Performance</p></th>
<th scope="col"> <p>Lieu</p></th>
Parsoid then serializes them on newlines but also moves the leading space to the next line which forces it to nowiki wrap it to prevent it from re-parsing as an indent-pre.
So, there are a couple issues here:
(a) Parsoid could leave the whitespace behind on the previous line which will eliminate the nowiki.
(b) But, fixing (a) will still serialize the content on a newline. To prevent that, either VE should not wrap content in <p>-tags or Parsoid could enforce normalization when serializing content in new table cells under certain conditions.
For now, I'll investigate (a) and see what is involved.
For whoever is debugging on the Parsoid end. Here is what I found out so far.
Looks like the serializer is unable to distinguish between the 2 separator scenarios in the two <th> tags and serializes them identically whereas the first one shouldn't get the <nowiki>, but the second one should. makeSeparator in wts.separators.js is the code in question.
<table><tbody> <tr><th> <!--a--><p>h1</p></th></tr> <tr><td>a</td></tr> <tr><th><p> <!--b-->h2</p></th></tr> <tr><td>b</td></tr> </tbody></table>
[subbu@earth:~/work/wmf/parsoid] php bin/parse.php --html2wt < /tmp/html
{|
! <!--a-->h1
|-
|a
|-
! <!--b-->h2
|-
|b
|}