It will be really useful to be able to accept/deny follower requests with Twitter API when tweets are protected.
This feature exists but currently this is not public.

When I try to call this endpoint :

POST https://api.twitter.com/1.1/friendships/accept.json?user_id=<follower id>

I've received : {"errors":[{"code":37,"message":"Not authorized to use this endpoint."}]} - HTTP Code : 403

If you are using a native Twitter app such as the Twitter app on Android, if you click on a link to a website, which uses "sign in with twitter" to authenticate the user, the user is forced to login again, even though they are already authenticated with Twitter in the native app.

In a perfect world this secondary sign in would not be necessary, and would reduce a lot of friction.

Specifically, some kind of way to download the csvs produced by exporting https://analytics.twitter.com/user/[INSERT DATA]/tweets given OAuth read (or even read/write) scope would be really useful

At www.contexto.io and www.graphext.com we provide our customers the possibility of mapping and expanding Twitter communities leveraging the social graph. This allows us to get really contextual, relevant and different insights that most social media analytics tools offer (they mostly count keywords that matches a boolean query).

We currently use the free API following/followers endpoints for this right now but with the new policy starting this month we cannot make more than 100K requests/day which prevent us from scaling our product. We would be very happy to pay for a premium endpoint like this!

It would be useful to be able to retrieve more than 100 results calling GET statuses/retweeters/ids
The current limitation doesn't make sense.

Currently we can access 1on1 DM via Twitter API but not group conversations. If we forcibly set the group's conversation_id, Twitter API returns forbidden. Allow this.
ref
https://developer.twitter.com/en/docs/direct-messages/sending-and-receiving/api-reference/new-event

It would be really helpful to have an analytics endpoint in which the entity was a media ID (in my case a video ID) and you could request engagement & video metrics aggregated at the video level, even if that video appeared across many different tweets. Right now this is possible through the Engagement API for video views only, but it would be great if it were available through the Ads API & included seconds/minutes viewed, percentile completions, call to action clicks, etc.

Describe the level commitment (and dedication) to APIs.

What are the thresholds for usage & overall sunsetting of service?

What criteria will be used to make significant changes?

Having access to an API for Twitter native polls would enable developers to create and schedule polls, as well as get back engagement data such as impressions, responses, Retweets of the poll, and their resulting responses, reach, and total engagement.

Tweet threads have become increasingly popular over the past few years. This API would enable developers to tap into the potential of threads by programmatically creating threads, as well as retrieving all Tweets in a thread.

Twitter could build a more affordable version of the enterprise Engagement API, which would provide developers with Tweet metrics for owned Tweets.

Engagement data returned by the API includes number of Likes, Retweets, replies, impressions, and engagements (for example, number of link clicks). This API would enable developers to better understand their reach and impact on Twitter.

I would like to recommend building a conversations API that enables developers to track updates to full conversation threads. This API would retrieve the entire conversation that a Tweet is in, and return all Tweets and replies within a given thread. This API would enable developers to go from a Tweet of interest to all replies in the thread, without having to recursively search for Tweets with the correct "inreplytostatusid".

Build a new request operator that can be included in an API request, and returns a translation of the Tweet text in the Tweet payload. Supported languages should be the same languages that are supported by the "lang:" request operator.

I would like the Twitter API to use OAuth 2.0 instead of OAuth 1.0. OAuth1.0a is fairly specific to the Twitter APIs at this point in time. It's complicated to implement, and there is a dwindling number of developer tools that support it. OAuth 2.0 is less complicated and easier to build into an app than OAuth 1.0.