Can Ghidra be enhanced to understand semantics?

[Wall-AF]

With the structure

struct HookMenuInfo32 {
    HWND         m_ahWnd[2];     // 4*2 bytes
    HMENU        m_ahMenus[8];   // 4*8 bytes
    int          m_anPos[8];     // 4*8 bytes
    HMENU        m_hMenu;        // 4 bytes
    int          m_nSubMenuPos;  // 4 bytes
    enumUINT_MFs m_flg;          // 4 bytes
}; // 84 bytes

Ghidra is producing code like

   for (i = 0; i < 7; i += 1) {
      if (menuInfo32.m_ahMenus[i] == NULL) {
         if (((1 < i) &&
             (hSubMenu = GetSubMenu((HMENU)menuInfo32.m_ahWnd[i], (int)menuInfo32.m_ahMenus[i + 6]),
             menuInfo32.m_ahWnd[i + 1] != (HWND)hSubMenu)) && ((HMENU)pCWPStruct->lParam == hSubMenu)) {
            menuInfo32.m_ahWnd[i + 1] = (HWND)hSubMenu;
         }
      ...
   }

which, whilst technically is using the correct memory locations within the HookMenuInfo32 structure above, semantically it is incorrect because of the faulty datatype casting (due to the compiler optimisation removing the original references and replaced them (as all elements withhin the structure are of the same base size - 4 bytes))!

The code sould look like

   for (i = 0; i < 7; ++i) {
      if (menuInfo32.m_ahMenus[i] == NULL) {
         if (((i >= 2) &&
             (hSubMenu = GetSubMenu(menuInfo32.m_ahMenus[i - 2], menuInfo32.m_anPos[i - 2]),
             menuInfo32.m_ahMenus[i - 1] != hSubMenu)) && ((HMENU)pCWPStruct->lParam == hSubMenu)) {
            menuInfo32.m_ahMenus[i - 1] = hSubMenu;
         }
      ...
   }

Is there a way to force Ghidra to use the corrected array that would then force the index calculations to be corrected? In theory, the knowledge that part of the equasions have been type specified should give Ghidra enough information to attempt this, or am I being too optimistic???