We would like to be able to create an SPFx form and associate it with the List/Content type Disp, Edit, New form so that no matter how a user finds a list item (search, OOB list view, custom list view, etc) they see our custom form. Currently our only option is to create a completely disconnected experience in which we write a custom list view that points to custom form pages.

Alternatively support field customizers with edit model to enable custom field editing experience.

Please provide a well-known placeholder for the property pane or better a similar placeholder that let us create a sidebar.

Having this ability would let us create powerful sidebars/toolbox extensions. This would be a super cool enhancement!

Provide option to enable\disable event firing from Remote Event Receivers in SharePoint Online (CSOM/API) similar to SSOM - EventFiringEnabled

It would be great if we are able to use font icons instead of url to images for Command Set extensions buttons icons.
This allow 3d party extensions look more aligned with 1st party (same style, same icon color)

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

Provide a SharePoint Framework mechanism/API that allows for Site or Site Collection Read/Write of Key/Value pair properties for use in SPFx related configuration and customizations. Similar to how the property bag was used in classic.

One use case is for storing configurable properties or even user personalization configurations written and read by an SPFx solution.

This is one of many uses cases that would make this feature valuable, so in addition to your vote, please feel free to comment with additional ways in which this feature could provide additional value.

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

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.

Provide a way to get data about all components that present on page in ApplicationCustomizer like SearchBox, Search, Documents Library, Lists, Navigation bar etc.

The idea is to have full control on user interaction with components.

In example I want to make an additional action when user clicks on folder, file, list item, navigation item, search result item etc...

Ideally to have access to domElement and data model of component.

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.

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.

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.

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