As an example - Angular2 provides an excellent user experience, especially when tied to Bootstrap (v3 or v4) suitable for creating immersive experiences where the whole of the SharePoint chrome is replaced (other than the top bar).

However integrating it with the SharePoint REST API framework is cumbersome and unless extensive work is undertaken to mock SharePoint the unit testing and rapid deployment is very unpleasant if possible at all.

The SharePoint framework provides a rapid deployment and unit testable mechanism for developing SharePoint functionality but is limited to single web parts and extensions.

Please extend the model so that it can be used to create single page applications in the framework of the developers choice.

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.