Ah, yeah, one of Ben Lesh’s threads. I mentioned him earlier as someone who was so vehemently against Hack pipes that he seemed to become disillusioned with TC39 more broadly.

He’s…somewhat of an outlier in the intensity of that reaction. I still don’t really understand why he places so much weight on tacitness of the primary argument, relative to linearization, to the point of wanting to shut the whole thing down. And I still haven’t seen a persuasive articulation from him of why tacitness matters that much more than linearization for fluency. I’m a fan of his work, but he genuinely seems not to see much value in linearization on its own, and I still don’t think I’ve seen a clear explanation from him as to why.

That said, it’s certainly possible that others will also feel emotionally ambivalent or opposed to Hack pipes’ explicitness. And that is a reason for some nervousness.
But it’s not as though we don’t also have reasons to be nervous about encouraging developers to switch to call-this and its heretofore-rare this-based standalone functions en masse, either…
No slam dunks here from the whole community’s point of view.

I hadn’t seen anyone make the connection between call-this and Reflect.apply until you have, but I would love to hear more about this

Basically, all of https://github.com/tc39/proposal-call-this/blob/main/README.md#:~:text=There%20are%20a%20variety%20of%20reasons%20why%20developers%20use%20.call and half of https://github.com/tc39/proposal-call-this/blob/main/README.md#call-is-clunky are already addressed by Reflect.apply:

-rec.method(arg0)
+const { apply } = Reflect
+apply(method, rec, [arg0])

It specifically remedies the subject–verb separation of .call, and actually does a better job of protecting against monkey-patching and prototype pollution by being immune from subsequent modification of Function.prototype.call itself... the only complaint it doesn't address is subject–verb–object ordering, which is also already possible to handle with helpers like

-apply(method, rec, [arg0])
+const callThis = (rec, fn, ...args) => apply(fn, rec, args)
+callThis(rec, method, arg0)

that's much better than method.call(rec, arg0) but empirically not by enough for widespread replacement of .call, and neither have been good enough to meaningfully encourage exporting collections of receiver-sensitive functions outside of a containing class, which I think is where a reframed call-this proposal has some room to work.

And regardless, I'm pretty much of the opinion that a data-flow perspective on call-this doesn't even make sense. Even the above callThis helper is intersects with pipeline on the same footing as any other function, and is less like to participate in a pipeline than e.g. Object.fromEntries. And while I don't consider it likely that pipeline would significantly encourage libraries to export functions rather than classes (because, as noted above, calling a method on a class instance gets the same pipeline DX benefits as calling a bare function), I do consider it likely that ergonomic call-this syntax would encourage libraries to export methods in addition to their containing classes for the improved tree-shaking

Yes, Reflect.apply does have several advantages over Function.prototype.call, including improving subject–verb separation.
I don’t think that really negates the “.call this is common and clunky” reasoning in call-this’s explainer, especially if it requires “callThis” userland helper functions in order to get SVO word order. It’s not like Reflector.call isn’t also clunky.

The real debate would probably be over if their use cases are compellingly common enough to warrant syntax—as I have tried to argue to the Committee on behalf of Jordan, with not much success.

export const {method} = C.prototype is not enough to get tree shaking... [method] is still subject to polymorphic/reflective use cases which are what make tree shaking unsafe.

Even if method is imported but C is not? I can believe that tree-shaking does not currently result in omitting unused parts of C in such cases, but updating to do so seems not just tractable, but exactly the kind of ecosystem change that would be expected as a second-order consequence of call-this.

obj..to(Object.entries).filter(fn1).map(fn2)..to(Object.fromEntries);

this is definitely true, but seems irrelevant. It's also already possible to get poor-mans-pipelines using helpers with names like flow or chainable, and I don't think introducing yet another approach via call-this further raises the bar for pipeline to justify its proposed syntax (that need exists regardless, although I guess one could make an argument that ..to(fn) is so much better that it does cover the pipeline use cases 🤷)