It is actually possible to import the definition of a XsltListViewWebPart via LimitedWebPartManager in CSOM. However, not all properties are supported. Important properties like XmlDefinition, Toolbar, ViewStyle, .. are being ignored. There's no possibility to have everything set correctly not even manipulating the backed view after importing the WebPart. Please read also this discussion:
http://sharepoint.stackexchange.com/questions/90433/add-document-library-xsltlistviewwebpart-using-csom-or-web-services

Need to do this in CSOM
$columnDefaults = New-Object Microsoft.Office.DocumentManagement.MetadataDefaults($list)
$columnDefaults.SetFieldDefault($Folder.Folder, "TestMMSColumn", "1033;#" + $term.Name + "|" + $term.Id)

It's currently possible to identify the features that are activated at the Site and Web level using CSOM, it isn't however possible to determine which features are present but not activated using CSOM. It would be great if this feature could be added!

Actually, the only way to paginate list items using the new REST APIs is to use __next property. There's no way to have a full working pagination using $top and $skip token as for any other REST call.
See my comment here:
http://msdn.microsoft.com/library/d4b5c277-ed50-420c-8a9b-860342284b72.aspx

At the moment it does not seem possible to create WebPart connections via the Client Side Object Model.

There is currently no good way to do enterprise level automated deployments of an SPFX addin into a SharePoint 2016 on Premise environment..

Consider a case where there are 1000 site collections and we would need to deploy an SPFX app to all sites automatically. Currently there is no way to perform this deployment in an automated fashion. It is not possible through powershell, csom, c# or in an administrative UI.

Having this ability would solve a large hole in capabilities with SharePoint Framework

Trying to unit test web parts results in an error 'Cannot find module "@ms/sp-telemetry"'. This can be due to using SharePoint dependencies e.g. 'SPHttpClient' when creating the React component. This totally blocks being able to unit test web parts, please fix this.

'@microsoft/sp-build-web' Seems to have been updated to remove the previously included testing modules, these do not have to be added back in, to resolve this issue, as we are able to find the most suitable testing modules to replace these.

This issue has been reported by other users:
https://github.com/SharePoint/sp-dev-docs/issues/526
https://github.com/SharePoint/sp-dev-docs/issues/1076
https://github.com/SharePoint/sp-dev-docs/issues/243

There's an undocumented API (https://tenant.sharepoint.com/_vti_bin/homeapi.ashx/ ) to follow sites and query data around those concepts. For corporate intranet scenarios, we often want to present the data a different way, surfacing native SharePoint capabilities. In order to add a "follow" button on an SPFX web part, we'd need an API to access that.

Related GitHub issue https://github.com/SharePoint/sp-dev-docs/issues/1689

There's currently no better way to configure search indexed and managed properties than export/import configuration. It's a huge pain when building search related apps and a black box, we need something better

When creating Site Collections through CSOM and providing an LCID. (For example 2067) an exception is thrown.

[Quote]
SiteCreationProperties.Template\r\nParameter name: Specified value is not supported for the SiteCreationProperties.Template parameter." is thrown at ExecuteQuery();
[/Quote]

The Exception is also not pointing in the right direction.
1) It should be possible to create Site Collections providing the LCID
2) When an Invalid Lcid is passed, the exception should point in the right direction.

Today, application extensions in SPFx (command sets, application customizers & field customizers) can't be tested within either the local or SharePoint Online hosted workbench. This is a bummer and a big step backwards to such a cool aspect to the development story with SPFx.

I get that you need a list to work with, but at a minimum, the workbench could have a static list with static data and no other functionality for us to test the customizations on.

My wish is that Microsoft adds support to the workbench for extensions before GA.

List items that have an Audience field attached should be audience filtered when retrieved via the REST API.

For example, a list that has link items with the Audience field attached to target particular items at particular groups of people. If the REST APIs are used to retrieve items from this list, then the identity of the requesting user should be optionally used to filter the results based on audience.

REST API should be fixed when getting single value Managed Metadata since it returns the Id instead of the actual value, which then requires another call to get the value. Without this you cannot show a list of items/docs with the single Managed Metadata value. Note that "Allow Multiple" Managed Metadata works fine as it returns a collection of actual values.

For details see: http://sharepointificate.blogspot.com/2014/05/taxonomy-columns-sharepoint-2013-list.html

Some list/library settings are available via CSOM. Others are available via the list property bag (although that approach is not desirable). However, there are even other advanced settings that don't appear to be accessible (read or write) via CSOM/REST. In particular, the advanced settings for "open documents in the browser" (open in the client application, etc.) or allow "quick edit" (yes/now).

I'm looking at SharePoint 2013 when trying to do this, but I suspect the same problem occurs for SharePoint Online and SharePoint 2016.

Right now there is no API to check that. If you add a security group into a SharePoint group, there is no way to check if the current user is a part of the SharePoint group: The user is not listed in the group.Users and the SharePoint group is not listed in the user.Groups. The 3 APIs that allowed to do this in full trust code are missing from CSOM so we need an alternative.

Remote event receivers can currently, in SharePoint Online, not be added to content types (https://msdn.microsoft.com/en-us/library/microsoft.sharepoint.client.contenttype_members.aspx). This makes it somehow tedious to catch events that are fired from items of a specific content type is added/updated/deleted. Having the possibility to add an event receiver to a content type would make this scenario easier to implement.

The latest version of the SharePoint Framework Yeoman generator contains a mix of features that are GA and preview features (for example connecting to MS Graph, web part connections, extensions). Whether the generated solution can be run in production depends on the features used to build the web part. With that, when bundling the project, the toolchain should warn of any experimental features being used in the project which would prevent the solution from being deployed to production tenants. This would help developers avoid deploying solutions depending on experimental features to production tenants, only to see the deployment fail.

When creating sites using a site design (recipe), one of the available verbs is calling an HTTP-triggered Flow to perform some additional configuration on the newly created site.

When installing SPFx solutions in a site, we should similarly be able to specify an HTTP-triggered Flow to be called as a part of the installation process. This would not only allow developers to provision configuration beyond what's currently supported with Feature XML, but also create a consistent development experience across the different workloads (site designs vs. SPFx).