Design goals:

• Format independent (I'm not going to specify a new format to store the serialize result)
• Configurable (e.g.: Devs can define their own structures that can be stored into indexedDB via structured clone algr)
• Async (Some data structures requires async access, including CryptoKey)
• Exportable (a interesting property on CryptoKey)
• Sendable (is it ok to transfer/clone to another Realm)
• Transfer (as structured clone, transfered data cannot be accessed later)

My current idea is

• defining a new kind of intermediate data structure (let's call it InterMap) which works like a Map
• design a set of API to ser/deser from/to InterMap
• let InterMap can be structure cloned

if A and B encode and decode the InterMap in different way, program will fail

e.g.

• app that 1 month ago vs app today (via indexedDB or other persistent storage)
• website a and website b (via postMessage or other communicating API))

obj.method~() would handle method extraction with implicit binding, which bind-this does not address. I’m talking about when the receiver of the bound function already contains the function that is being bound. Bind-this would require you to repeat the receiver in this case; it does not address method extraction at all.

n.on("click", v.reset.bind(v))
n.on("click", v::v.reset)
n.on("click", v.reset~())

Of course, PFA syntax does not address changing the receiver of a function call.

isPending.call(this._target())
this._target()::isPending()

PFA syntax and bind-this can also work together, when creating bound functions with multiple partially applied arguments, which people sometimes do use bind for.
From svgo@1.2.2:

smartRound.bind(this, params.floatPrecision)
x => this::smartRound(params.floatPrecision, x)
this::smartRound~(params.floatPrecision, ?)

class C {}
function g() { return new C(); }
const o2 = g(); // C {}
const o3 = new g(); // C {}

const x = module function f(a = expr()) {
}

A partial application of new C~() would make the new part of the result, regardless as to whether C is a class or function:

function C() { }
function g() { return new C(); }
const o1 = g(); // C {}
const o2 = new g(); // C {}

if we don't have new in partial application, the behavior is the same as .bind:

function C() {}
const g = C~();
const o1 = g(); // undefined
const o2 = new g(); // C {}

However, not having new feels strange in this example:

class C {}
const g = C~(); // doesn't throw
const o1 = C(); // does throw, must use `new C()`

I'm fine with have partial application without new (in the partial call), if necessary. I still feel that its unfortunate we don't have a built-in way to allocate a class instance via callback w/o having to defer to arrow functions. If we had Function.prototype.construct (to mirror Function.prototype.call/Reflect.construct) I might be less concerned with supporting new C~().
Something like:

Function.prototype.construct = function (...args) {
  return new this(...args);
};

class C {}
const o1 = C.construct(); // C {}
const g = C.construct~(); 
const o2 = g(); // C {}

PFA syntax does not address the clunkiness of this:

// bluebird@3.5.5/js/release/synchronous_inspection.js
isPending.call(this._target())
this._target()::isPending()

…or this:

// ajv@6.10.0/lib/ajv.js
validate = macro.call(self, schema, parentSchema, it);
validate = self::macro(schema, parentSchema, it);

At most they overlap somewhat when the receiver object itself contains the function to which we wish to bind. In that case, PFA syntax would be terser than bind-this, because bind-this would require repeating the receiver.

n.on("click", v.reset.bind(v)) // Note how v both contains v.reset and is the receiver of the function.
n.on("click", v::v.reset) // bind-this
n.on("click", v.reset~()) // PFA syntax

That is understandable.
Do note that bind-this and PFA syntax could also work synergistically.

// svgo@1.2.2/plugins/convertTransform.js
smartRound.bind(this, params.floatPrecision) // Original
x => this::smartRound(params.floatPrecision, x) // bind-this only
this::smartRound~(params.floatPrecision, ?) // bind-this + PFA syntax

Anyways, I view PFA syntax and bind-this (and pipe operator) as pretty orthogonal. I understand Yulia’s desire to see if there’s a grand unifying syntax that could address all of the use cases, but I think the old bind operator kind of tried to do that and got stuck in the muck. bind-this, at least, tries to solve only one problem: .call/.bind are very common but are very clunky. Because of that, it can combine with PFA syntax or the pipe operator or whatever well.

IMO one nice little detail of hack pipes is that they can be slotted into the middle of a method call chain without changing any of the surrounding code

arr
  .map(f)
  .filter(g)
  |> customMethod(%) // added later
  .reduce(h, unit)