Excel Bug with global relative references

This is a desperate attempt to contact Microsoft, whom I seem no longer able to contact in any shape or form.  (My ability to log "service requests" as TEAMS admin has vanished.)  If any reader here knows how to log bugs with Microsoft, then please let me know / log this bug on my behalf.

Description of the bug:

We have a very complex production environment based on large Excel sheets.  After some recent code changes, I now occasionally receive random results from my calculations.  An investigation into the issue leads to breaks in the calculation tree.  These breaks occur around (named) global relative references, eg A4=CellU1, where CellU1 is defined as “=!A3”. 

I have not been able to reproduce the breaking calculation tree in a noddy sheet.  HOWEVER, I witnessed very similar behaviour about two years ago when once I used Application.CalculateFull from within VBA.  The relative references back then RELIABLY broke.  I did not think much of it because Application.Calculate DID NOT produce these errors, so at the time that was good enough for me.  And during these past two years I never observed this problem within the normal calculation tree (F9). 

I recalled this experience when I recently spent a day investigating this problem through our production environment.  I am glad to report that I was able to reproduce the problem again with two very noddy spreadsheets.  While the bug generation once more relies on VBA, I think you can see from the astonishing results that the bug itself does not relate to VBA.  I think when you trace down the bug I reproduce here, you will also fix the bug that affects our calculation trees.

How to reproduce the bug:

Attached are two tiny spreadsheets.  Load ExcelBug2.xlsx into your Excel session.  It is trivial.  The sheet uses =CellU1 to propagate down “Hello” and “World!”.  Nothing remarkable (if we ignore my use of these very arcane references).   Now load into the same Excel session ExcelBug.xlsm.  Enable Macros.  Trust me, the macros here are extremely basic.  The Auto_Open function is principally designed to force your Excel into Calculation/Manual and to turn off AutoSave.  (This is done in our production sheets for performance reasons.)  Whether this has any bearing on the bug is for you to work out.

There is a second macro called “showProblem”.  Analyse it (ALT-F11).  It simply multiplies INPUT by 2 and then triggers Application.CalculateFull.  I have linked this macro to a Button in the spreadsheet.  Be brave – press it.  As often as you like.  You will see INPUT double and OUTPUT will show the right result.

Now switch back to ExcelBug2 within the same session.  It too recalculates whenever you press the Button.  I get this picture:

This is of course total garbage.  When I press ALT-CTRL-F9 (ie trigger a full recalc from the keyboard), I get:

This is the expected result.  (A simple F9 will not find there, since Excel thinks it is all done calculating.)

Evaluation of the bug:

Looking at the garbage, it would seem to me that CellU1 in ExcelBug2 is evaluated within the wrong worksheet context.  It looks like these relative references find themselves referring to the sheet from within which the calculation was started when their anchor reference should of course be their own cell coordinates (inc worksheet).  (I have not found out which random source our spreadsheets draw from when pressing F9.)

Work-around for this bug:

The desired functionality can be retained and the integrity of the calculation restored by demoting the global name into the local scope of each sheet using it.  That is, we must replicate the same definition umpteen times over within a workbook.  I developed a VBA script to do this across our domain.  Not pretty, but needs must.

Please fix with urgency.  Thank you.