During Windows installation it thinks that EFI partition is not in fat32, but it is in fat32

I am surprised that running manually bcdboot against the ESP did not perform the trick; in fact, it could even been seen as a bug of it (meaning to be reported to Microsoft.) Are you 200% sure that you identified correctly what your firmware believes is the system partition?

The EFI system partition is not the only place to clean, the EFI variables (controlled by the UEFI firmware) could also be corrupted, particularly since you mentioned the BIOS reinstall had adverse effects. bcdedit /storeP:\ath\to\BCD\file\on\mounted\efi\part/import /clean (from the command prompt of the advanced options of W8 recovery) is the Windows' way to clean its cached copy, which copy is what you are really seeing on Windows boot manager screen; Linux offers, through efivars, even more powerful tools over them.

While you are here, follow Rod's advice and check thoroughly the output of bcdedit /storeP:\ath\to\BCD/enum all for unneeded or misplaced entries, which you could try to dispose of after having made a backup of the BCD file.

If you consider only Windows, the organization of the ESP is straightforward: besides the mighty Bootx64.efi, everything is under the \EFI\Microsoft\Boot\ directory. The only file you might edit is the BCD, through bcdedit. To be able to boot, you need just \EFI\Boot\Bootx64.efi, \EFI\Microsoft\Boot\BCD, and \EFI\Microsoft\Boot\boot.stl on the ESP, assuming the former is a copy of \EFI\Microsoft\Boot\bootmgfw.efi; keeping this later is a good precaution, particularly since you are considering the installation of other boot managers which could replace the mighty Bootx64.efi (but should generally left untouched bootmgfw.efi.) During the boot process, some (hidden) BCD.log* and BOOTSTAT.DAT files will be automatically created in \EFI\Microsoft\Boot\. You might also see \EFI\Microsoft\Boot\bootmgr.efi, although nobody seems to know what it is good for... The ll-CC directories with the MUI resources help to be able to display non-English messages instead, depending of the settings in BCD; similarly, the fonts could be needed for non-Latin cases; I found out that removing all this i18n stuff for cleaning purposes, did not help on the long run, since I use to turn them back in place, to get back my own language while booting.

This sounds like Windows doesn't like the FAT32 that's currently written to your /dev/sda1. Perhaps the disk once used NTFS and Windows is finding some remnants of that...? Working off of that (admittedly iffy) hypothesis, you might try this:

1. Back up the ESP. A file-level backup using cp, zip, tar, or something similar should suffice.
2. Unmount the ESP.
3. Wipe the ESP completely clean with dd, as in dd if=/dev/zero of=/dev/sda1. Be very careful with this command! If you specify the wrong partition, you'll be in deep trouble!
4. Create a fresh FAT filesystem on /dev/sda1, as in mkdosfs /dev/sda1.
5. If necessary, update /etc/fstab with the new filesystem's "UUID" or label.
6. Type mount -a to re-mount the partitions, including the ESP.
7. Use df /boot to double-check that the ESP is correctly mounted.
8. Copy the backup back to the freshly-formatted ESP.
9. Double-check that your critical files (your kernel and boot loader) are present.

You could do something similar using a Windows emergency disk if you wanted to ensure that the filesystem is something that Windows will find palatable; but I don't know the specific commands you'd use to do this in Windows.

Another possibility that occurs to me is that Windows might have a bug that's causing it to misidentify your ESP because of its size. For a while, Windows created an ESP of just 100MB, IIRC. I think that it's bigger than that now, but it's still well short of the 1GiB ESP you've got. Presumably you've made it that size because you're storing Linux kernels there, which is a common practice among Arch users. This size is therefore quite justified, but if it is causing Windows to flake out, you might need to delete the ESP and re-create it as two partitions -- either create two ESPs, one for Windows and one for Arch; or create one /boot partition for Arch and another ESP for both OSes, to be mounted at /boot/efi in Arch. Personally, I think this explanation is far less likely than that Windows is seeing stray (old) data or some slightly malformed FAT data structures and is flaking out. After all, Windows can handle much larger FAT data partitions. Still, if re-creating the ESP as outlined earlier doesn't work, splitting it into two partitions might be worth trying.