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 = [
{
"id": "room1@contoso.com",
"type": 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 = [
{
"id": "room1@contoso.com",
"displayName": "Room 1 - 6 persons",
"type": 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.

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.

It's been over 20 years since the VBA IDE was created in its present form. MS has since created a number of modern and efficient development environments. Even if the VBA environment has long been referred to as outdated: it is simply the everyday reality for the majority of professional Office developers (especially all serious Access developers). I can not imagine that it lacks capacity to MS to bring the VBA IDE into a more contemporary form.

To insist that it would not be worthwhile to invest in an improved IDE, is roughly as if an automaker refuses any further developments in the wheels for 20 years, with the note that they would someday replace all wheels by air cushions.

I am thinking about things like "real" IntelliSense (comparable to that in current Visual Studio languages), extensive auto code completion, syntax checks that support the coder and do not hinder him/her, a much better integrated help system, refactoring tools, etc..
In other words: Not a newly decorated IDE, but simply an up-to-date developement tool like those in modern IDEs (Visual Studio, Eclipse, NetBeans, IntelliJ IDEA etc.). I do believe that this would not be "old wine in new bottles" but a valuable "productivity tool" for all Office developers.

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?