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.

While the SharePoint online version is supported, we would like to see the SharePoint on-prem versions (SharePoint 2016/2019) supported with .NET standard CSOM APIs.

https://sharepoint.uservoice.com/forums/329220-sharepoint-dev-platform/suggestions/16585795-support-net-core-with-csom
^ this only allows for SharePoint Online .NET Standard CSOM support.

Many customers have significant investments and longer term roadmaps to get to SharePoint Online, but in the interim would like to start developing solutions that can be more easily converted to work in SharePoint Online along with being able to leverage the latest version of the Microsoft technology stack - that is growing the skillsets / toolset familiarity without waiting for longer term plans to move fully to SharePoint Online.

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.

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.

Either I'm missing something, or SharePoint Spaces is a completely manually created environment.

So other than some of the objects/webparts supporting data from other sources (e.g. SharePoint lists/libraries) within the bounds of that webpart, there's no way to programmatically add content to a Space.

Or should we be able to build SharePoint Framework webparts that can then interact inside the Space?

We're working with a partner on geospatial data (maps, terrain, satellite photos, building geometry, building scans, services data (water pipes, electrical wires, etc) and more), which is currently visualised using a customised version of the Cesium Viewer, but it would be great to bring this data into a SharePoint Space instead, perhaps integrating/merging with data from SharePoint lists...