Let me throw a few other items onto the pile:
7. New Primary Keys for Space Keys and Content Properties. The new API transitions off space keys and content property names, and instead, uses unique IDs for each (which apps never used to need to know). This is another paradigm shift which does not map 1:1 to the old API and which likely requires more architectural rework to (for example) communicate and store spaceIds instead of spaceKeys in various places throughout the client app.
8. Different Response Shapes. The shape of almost all of the API response objects has changed. This creates a higher testing burden on vendors because they are not 1:1. In addition, until 100% of the V.1 API is fully transitioned, apps need to awkwardly translate between one shape and the other internally, which is awkward at best and error-inducing at worst.
9. Performance Parity. Atlassian has said that they are willing to trade off receiving more API calls in exchange for the increased permission granularity. While Atlassian may be able to handle the load, the problem is that this can translate into significant speed slowdowns for the end user, because one API call often turns into 2-3. Even if Atlassian can bear the increased load, will all of our collective end users be able to bear most apps being noticeably slower? Achieving “API parity” needs to be measured not just in completeness of API calls, but also speed. And by speed, I mean real-world use cases. This has to extend beyond only the simplistic testing of the speed of one V.2 call vs V.1, because there is no real 1:1 mapping between the two, and what was one API call often becomes multiple. (At least one or two other vendors have already posted comparisons, and I would generously describe them as “not good”.)
10. Rate Limiting Increases and Transparency. There is talk of greatly expanding the number of API calls made by apps, but it is not mentioned anywhere how (or if) the rate limiting limits will be adjusted. In passing, these limits were already rather opaque to begin with.
With regards to the CQL search API as a workaround, as I may have mentioned elsewhere, this is not a suitable replacement for “fetch-content” because it depends on the search indexes being up-to-date. These indexes were apparently designed for eventual consistency, but if you do something like creating some content and then trying to fetch it immediately via search (from somewhere that happens to hit the wrong replica), you won’t necessarily find it. I also get the impression that the team would like to deprecate the V.1 search API, although they haven’t (yet) figured out how, so it has not been announced.
In response to feedback, Atlassian did provide this new API to batch-convert a list of contentIds to their appropriate types, although this still means that you will need to rearchitect your app to convert and store old contentIds as new tuples of (contentType,contentId). This is another non-trivial task that most app developers will need time to implement and test.