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.

When developing a SharePoint Framework Extension to display a custom header and/or footer, the SharePoint Composite Header can be very redundant to the custom header.

The Composite Header (css classname is 'ms-compositeHeader'), is what SharePoint provide out of the box and includes the square site logo, site name and navigation.

When creating your own custom header that includes all of these things and possibly more, the existence of the Composite Header is redundant and can be confusing for users...(Ex: redundant navigation).

While CSS can be used to hide this, such a technique is not playing within the rules of only controlling the DOM elements created by the extension.

This request is to have a configurable property created that can hide the composite header to remove the redundancy when creating a custom header.

This could be a site property configured using PowerShell or a property defined in the SPFx Extension itself.

This would help ensure that rogue overriding of the CSS to hide the Composite Header does not occur and helps developers to stay within the rules requested by Microsoft when developing for the Modern Experience.

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 ;) ).

It would be nice to have the ability to extend some of the functionality in the SharePoint Admin Center. Specifically, the ability to deploy SharePoint Framework Web Parts into the Admin Center (via an App Page?). Currently, the community builds lots of SPFx Web Parts to fill the gaps in the Modern UX.

Such Web Parts include:
Theme Manager
Site Design Studio/Manager

These are SPFx solutions that have been built to help better manage our environments through a UX experience (as there isn't one via First Party). It would be nice to have a centralized location where these SPFx solutions can live and be used.