There is no obvious way to get details about a recurring calendar events through the CSOM or REST API.

When querying a calendar list only one item is returned for the calendar recurrence item. Only one field identifies this is a recurring item. the fOccurrence field is a boolean field.

When using the server side object model, properties are available to expand recurring calendar events to get the individual recurring items.

The only way to do this for client applications is to go back to using list.asmx which is not great and I'm not sure how long this will be supported.

Not having this makes the use of calendar lists in apps (SharePoint hosted, Display Templates and Client Side Rendering) useless.

Besides the lack of detailed documentation around the REST API, given its importance as a major entry point for apps, it needs to be treated with more respect as a service offering. It's currently being updated in CUs and on SharePoint online without any notification of the changes being made (such as the $metadata endpoint appearing - was it in the August 2013 CU for on-prem?). We either need it to be released in a non-breaking change model (URL versioning such as the Twilio model), or messaging needs to be improved so we know when things are going to be changed. Having a log of changes that have been made to date would be helpful, along with understanding what changes are currently in the queue. For example, I would LOVE to know if the end game for the _api endpoint is to finally be a first-class OData v3 endpoint sometime soon.

We can do templating on SharePoint, through Site Designs and Site Scripts. We now also have the option to "Create a Microsoft Teams from Template".
Unfortunately, both do not work together. We either have a templated SharePoint site with a generic Teams or a templated Teams with generic SharePoint site.

I would love the possibility to combine both templating options. Preferrably with an API from day 1.
This would give us an end to end templating scenario, where we can create preconfigured Teams with a preconfigured SharePoint site. (In the future, hopefully with a preconfigured Planner etc as well ;) ).

Currently working with the API's for drive, graph, sharepoint are very difficult due to the throttling that can be encountered.

Each api offers different guidance to avoid throttling. Example are:
1) use a special user-agent header
2) respect the retry-after header

Speaking with microsoft representatives they instruct us to perform major api processing in off peak hours. Additionally tenant's can have hard locks placed on them.

This request is to get better information around tenant usage returned in the API's.

1) If a tenant is hard locked, tell us in a distinct message so that don't just hammer the requests over and over again.
2) Give us feedback in our api calls regarding the health of a tenant. If we are approaching a threshold limit, give us some type of header we can use to instruct us to slow down our requests.