The dewiki issue turned out to be unrelated to table fixups. Fixed with this edit.

The issue can be reproduced with this snippet:

{|
{{1x|
{{!}}a
}} ||b
|}

{|
{{1x|1=
{{!}}a
}} ||b
|}

The difference is seen with --dump tplsrc as below:

php bin/parse.php  --dump tplsrc < /tmp/twt
[dump] ============================ template source ============================
TEMPLATE:Template:1xTRANSCLUSION:"{{1x|\n{{!}}a\n}}"
--------------------------------------------------------------------------------

|a

--------------------------------------------------------------------------------

[dump] ============================ template source ============================
TEMPLATE:Template:1xTRANSCLUSION:"{{1x|1=\n{{!}}a\n}}"
--------------------------------------------------------------------------------
|a
--------------------------------------------------------------------------------

Use of unnamed argument syntax causes the preprocessor to pass back the newlines. It is kinda risky to trim trailing whitespace in the preprocessor this late in the game without careful testing. Worth checking Parser.php as to how this difference is handled without introducing the same diffs in legacy output.

As for the trwiki page, here is a sample snippet from the table in question:

|-
|[[Beşiktaş (futbol takımı) 2024-25 sezonu|2024-25]] || [[2024-25 Süper Lig|4.]] {{WDL|20|10|6|4|for=34|against=18|diff=yes}} | width=30 style="border-right:2px solid grey;"|'''36''' ||{{#expr:36/20 round 2}}0|| {{#expr:34/20 round 2}}0 || width=30 style="border-right:2px solid grey;"|{{#expr:18/20 round 2}}0 ||align=left|{{bayraksimge|TUR}} [[Serdar Topraktepe|Topraktepe]] <sup>g</sup> {{küçük|''(3 Maç)''}}, {{bayraksimge|NOR}} [[Ole Gunnar Solskjær|Solskjær]] {{küçük|''(17 Maç)''}}

Specifically see this bit: {{WDL|20|10|6|4|for=34|against=18|diff=yes}} | width=30 style="border-right:2px solid grey;"|'''36''' . And, the expanded template output here is the same as with the dewiki case where there is a trailing newline. But, in this case, the weird thing is that the new-cell is separated with a | instead of a || as you would expect for same-line-row wiktext which means the newline is also present when legacy is processing this. Changing that to || breaks legacy output because on a newline, || is empty attribute and the width becomes content. But, Parsoid treats that properly because it tokenized as a <td> by peg at the top-level. So, no tablefixups involved here as well.

In this case, the best fix is to edit the page and add a newline break in source before | width=30 which is more in line with how the wikitext behaves given the newline-table-cell-syntax used in the table.

But, it is possible that there are many pages on trwiki impacted by this given that this is a sports page and it is likely there are other sports pages with similar wikitext usage. If so, we might be forced to support this weirdness in TableFixups by having it handle it.

The trwiki example can be reproduced with this snippet:

{|
| [[A]] {{1x|{{!}}{{!}} B
}}| C
|}

Since Parsoid tokenizes table cells independent of the top-level page, the "| C" is tokenized as a string since the template's content is opaque. TableFixups exists for this scenario, but it currently handle this fixup case where the template's content ends in a newline. While we could implement this in Parsoid, it is actually better if we don't because the wikitext in the general case would be `| Foo {{template}} | Bar and it is not obvious to the editor either that the | Bar is a new table cell. In typical table wikitext, that would have to either be: || Bar or start on a newline. An editor looking at that string doesn't know that the {{template}} ends in a newline.

So, my proposal is to fix the trwiki pages to add a newline after the {{WDL..}} uses on the ~250 pages that it is currently used on.