Should we support optional variants of eventual methods?

[JLHwung]

For example they can default to the optional access, or for delegated promises, calling the associated handler trap.

Static Method	Default Behavior	Handler trap
eventualOptionalGet(p, prop)	p.then(t => t?.[prop])	h.eventualOptionalGet(t, prop)
eventualOptionalApply(p, args)	p.then(t => t?.(...args))	h.eventualOptionalApply(t, args)
eventualOptionalSend(p, prop, args)	p.then(t => t?.[prop](...args))	h.eventualOptionalSend(t, prop, args)

Note that for eventualOptionalSend, there are two optional behaviours, though the usage is expected less common

p.then(t => t?.[prop]?.(...args));
p.then(t => t[prop]?.(...args));

Alternatively, users could provide own handler for such behavior, likewise for other methods.

{
  eventualGet(target, prop) {
    return target?.prop
  },
  eventualApply(target, args) {
    return target?.(...args)
  },
  eventualSend(target, prop, args) {
    return target?.prop(...args)
  }
}

But given that optional chaining is very handy on error processing, it would encourage the usage of handler traps for such a simple use case, which I think is a bad practice.

The broader question behind this one, is in what extent the eventual should methods map to the LeftHandSideExpression. The current eventual methods covers common operation like
some productions of call expression

CallExpression:
  PrimaryExpression ( Arguments );
  PrimaryExpression [ Expression ] ( Arguments );
  PrimaryExpression . IdentifierName ( Arguments );

and some productions of member expression

MemberExpression:
  PrimaryExpression [ Expression ];
  PrimaryExpression . IdentifierName

The OptionalExpression is not mapped by any event traps, nor is NewExpression (#19) or nested member/call expressions (tc39/proposal-wavy-dot#10, tc39/proposal-wavy-dot#11).

Related: tc39/proposal-wavy-dot#8