Provide a download for the Inquire Add-In that will work with Excel 2016 Professional, not Pro Plus.

Is it possible to have a workbook that uses the ProgressBar control
from mscomctl in 32-bit Excel, but does not use it (and does not give
the user an error) in 64-bit Excel? Currently when I open the workbook in 64-bit Excel, I get an error that it can't find the library.

Please add 'cross references' in the code for navigation. e.g. where a function/sub is called, if the user doubleclicks or crtl+clicks on the function/sub then they get taken to it

...without having to do this...press Windows+R (Run), then type “Excel /x” without quotes. This is not efficient

Excel 2007 supported a calendar control reference that allowed the programming of a pop-up calendar for date pick on worksheet_change. This function has been stripped from newer version of excel. The convenience of this reference can't be overstated, and ensures correct date format.

For decades Excel's Application.WorksheetFunction.Match has had return type Double, as shown in the VBA object browser. This means it throws runtime errors when there's no match for its 1st argument in its 2nd argument rather than returning an error value (#N/A).

Since Application.Match does work more as nearly all users would expect, is there some reason Application.WorksheetFunction.Match can't work exactly the same as Application.Match? If not, why can't Application.WorksheetFunction.Match work exactly the same as Application.Match?

Sort arrays both single and two dimensional as well as being able to groups and sum array elements. As arrays run 20x faster than normal VBA code this would make programming fast running macro's much easier.

VBA Forms not working in MS Office 365 ProPlus version 17.0 which got released recently on May 9th, 2017. The Macros are getting crashed throwing the error 1004: Application-defined or object-oriented error. Until Version 16.0, Macros worked fine.

We have been advised to consider upgrading to the 64-bit version of Office throughout our company. As a world leading financial institution we have a lot of users that use Excel applications that require large amount of memory and processing power.

We have a dedicated VBA development team that make extensive use of the controls and we need 64-bit versions of the controls before the roll-out can go ahead as a large number of critical applications will no longer work in 64-bit Excel.

DO NOT let us do scripting with Python! Yay!

Modify the stock analysis template in excel 2016 to allow those stocks listed on Yahoo.Finance. For instance, I cannot add D05.si

Currently User Defined Functions (UDFs) in Excel will not show intellisense to tell the user what arguments need to be supplied. This makes them very difficult to use.

There's a discussion here:
http://stackoverflow.com/questions/16903587/the-quest-for-the-excel-custom-function-tooltip

Whether the future of UDFs is in VBA or something else, the ability to define intellisense is vital.

There is currently no event when an autofilter is changed. The autofilter could be in a normal range or in a table.

The current workaround is to create a hidden sheet with a formula that references the cells on the sheet with the autofilter and to catch the WorksheetCalculate event in order to know when someone changed or cleared an autofilter. Additionally for this to work, calculation must be set to Automatic. http://stackoverflow.com/questions/28979396/excel-vba-filter-change-event-handler

Users should be able to Right-Click on a column in the Power Query editor and have the option to hide the column from view when it is loaded. Currently the only option is to completely remove the column altogether....

Range.Text should be able to return an array of results instead of only being able to return the text for a single cell. Its behavior should be consistent with Range.Value and Range.Value2.

Additionally, Range.Text should never return a result like '#####' when the column width of the cell is too small. It should always return the text that would be visible if the column was wide enough (and calling Range.Columns.AutoFit before calling Range.Text should not be necessary).