Twilio's problem is that they keep growing in features while being forced to maintain stalwart backwards-compatibility WHILE maintaining documentation AND a ~dozen client libraries for all their developers. While they've made a concentrated effort to improve their documentation / interface over the past year, it's not uncommon for documentation to be out-of-date or incorrect or libraries to be confusing (client.messages.new might call the 2009 endpoint and client.newMessage might call the 2014 endpoint, with only the later endpoint accepting SMS bodies <= 1600 characters for example).

With new offerings like Copilot and presumably this, they get a chance at a fresher start BUT unless you want to handle interacting with Twilio's endpoints directly you're going to have to wait for your client libraries to catch up, which might not be a problem with NodeJS, but for instance my company uses a third-party Golang library that's two years old and has only received minor tweaks in the past 6 months. It will probably not be updated with new features soon or ever, and should I want to utilize these new features I would have to extend or re-write the library myself.

Finally Twilio provides no ways of including metadata in an SMS submission (which is a huge freaking oversight) and makes it very difficult to associate a number with an account. The most accepted answer for that problem currently is to use the Twilio number as a foreign key for an account, which a) does not work with Copilot as you have no control over which number will send the message and b) requires each account to have its own ($1) number, which does not scale.