Workflow target filter expression evaluation is broken

Taskrouter expressions are a great concept that allow more dynamic routing not constrained to a traditional hierarchy, while also reducing the need for infrastructure. The idea is great: set up your routing rules and filters, and you're up and running.

The implementation however, is broken to the point that it's only usable in the most simple cases:

Optional properties

Example scenario:
If a worker transfers a chat back into the queue, dont route the chat directly back to them.

The documentation states:

If the document does not contain the requested key, it resolves to NULL

based on this, I should be able to easily address this by setting a property on the task to be transferred containing the agentSid to be ignored. Then creating a rule in the filter target like so:

worker.sid != task.ignoreAgentSid

Indeed, this works correctly for transferred chats:

However, on new incoming chats that don't contain the property ignoreAgentSid, the statement is never evaluated as true. This is indisputably broken.

In my testing I found a disparity between evaluating taskQueue rules, and workflow filter target expressions. Task Queue rules largely follow the documentation and can easily be tested just by viewing what workers match the current expression.

Works as expected, matching all workers (within task queue expression):

sid != null

works as expected, matching all workers (evaluating non-existing properties):

foo == bar

Twilio's inaction

I've contacted twilio support regarding this issue previously. Other than a vague "we'll look into it", communication has been radio silence.

Does anyone know if they're abandoning the concept of the expressions in routing? While I do get that you can defer to a webhook to define routing, that's more infrastructure to maintain, and is not nearly as accessible to non-coders. I would wish that what they already provided would work as claimed.