I'd like to provide some feedback about Office.EnhancedLocation and Office.LocationIdentifier when developing an Outlook add-in.
First, very happy to see improvements with this!

In my use case, I have an Office Add-in that show me all available meeting rooms (from a different Office 365 tenant). Users can add one or more of those meeting rooms as a location to the invite, through the add-on. Sending the invite, also books the room (and because of an Organization Relationship we can even use the schedule builder to view Free/Busy).
My code would use the EnhancedLocation.addAsync with body:

var locations = [

{

    &quot;id&quot;: &quot;<a rel="nofollow noreferrer" href="mailto:room1@contoso.com">room1@contoso.com</a>&quot;,

    &quot;type&quot;: Office.MailboxEnums.LocationType.Room

}

];

If room1@contoso.com is a room in our own tenant and exists in our GAL, the location gets updated with the displayName of the room "Room 1 - 6 persons".
If it is a room in the other tenant (and thus doesn't exist in our GAL), it just shows the e-mail address as location.

Preferrably, I would like to do something like:

var locations = [

{

    &quot;id&quot;: &quot;<a rel="nofollow noreferrer" href="mailto:room1@contoso.com">room1@contoso.com</a>&quot;,

    &quot;displayName&quot;: &quot;Room 1 - 6 persons&quot;,  

    &quot;type&quot;: Office.MailboxEnums.LocationType.Room

}

];

With custom locations, they could also use the displayName property and have their own "unique identifier" in the id field. The API would still be consistent.
And with rooms that do exist in the GAL, it could still resolve first with GAL and use the displayName is a fallback mechanism.

With the preview release of "the new Outlook" on OWA, Office Add-ins are now buried in the drop down context menu in an email. Additionally, it appears they do not follow the same behavior of Outlook on the desktop, where Office Add-ins will show in the larger ribbon if used more frequently.

According to this article, Office Add-ins can be pinned if they are used frequently:

If you were using add-ins in the classic Outlook on the web experience, they will show up pinned next to mail actions or in the drop-down menu once you open an email in the new experience. You can also install more add-ins from the Office Store—simply open an email, click the drop-down menu, and select Get Add-ins. Once installed, add-ins will show up in the drop-down menu. You can also choose to pin frequently used add-ins.
While I can instruct users to pin this for themselves, it does not appear that Office Add-ins can be pinned by an administrator.

For this feature, it would be great for administrators to be able to customize which add-ins are immediately available to the user by pinning them. Office Add-ins being buried in the menu of OWA is not helpful in this regard.

Word Interop is a nice solution, yet very slow (comparing to OpenXml) and unreliable (we encountered that if a user clicks Ctrl+C to copy something, whilst Interop is running in a background, generating multiple documents, its content will be pasted onto one of those documents, although the user intended to paste it somewhere else) . There are 3rd party solutions to save as PDF from OpenXml, yet they do not render correctly our relatively complex invoices (header with image and table, footer with table and so on), so for now we ended up to generate them all as docx and then run Word Interop from a server to convert them into pdf, using SaveAs2 method.

It is very difficult to test add-ins against multiple versions of Office and on different platforms.

For example, I ran into an issue where I had the latest macOS but a user had an older version. It was very difficult to debug and test code against that older version.

Therefore, it would be nice to have something like https://www.browserstack.com/ or Sauce Labs that was available to Add-in Developers so that we could run some automated testing in CI to make sure our changes will work on multiple platforms and environments. Maybe even at a minimum a set of VM's like what the Edge team provides to give users the ability to at least manually test against various platforms.

There should be a way for an Office web add-In to modify existing styles, list templates, and document variables without closing and reopening the document. The JavaScript InsertOoxml method allows you to introduce new styles, list templates, and document variables to the active document but not to modify existing ones. The same was true of the VBA InsertXML method. However, VBA provided easy, direct access to these objects via Document.Styles, Document.ListTemplates, and Document.Variables collections. For example, in VBA, modifying a style was as simple as ActiveDocument.Styles(“NameOfStyle”).Font.Size = #. In contrast, it appears that the only existing objects outside of a document story (the body, headers, footer, etc.) that you can access via the Word-specific JavaScript API 1.3 are document properties.

With office 365 word add-in development it is not possible to get all existing styles in a word document using word JavaScript API with as strongly type object of the API. The only way is using ooxml document. But the problem is this ooxml file size depend on the size of the word document. For an example, for 4-5 simple word paragraphs, ooxml size is nearly 13-15 pages. So it is very difficult to process styles in a large document using this ooxml. In VB and VBA, we can get all used styles through the API. So could you please consider about this request to implement get all styles through the API directly?