There are several questions about inc files.
1. If there were no functions in the file (For example SetWindowLongPtrA/W in USER32.INC) I had to added them to the original .inc
2. If I want to call the function RtlZeroMemory from ntdll I had to comment it out in the KERNEL32.INCs to avoid compiler errors

Question: Is it possible to avoid changing the original distribution files so that when updating fasm I don’t have to make these edits every time?

And one more off topic clarification:
The .inc files from https://github.com/tgrysztar/fasmg sometimes differ significantly from their counterparts in the official distribution (fasmg\examples\x86\include)
As far as I understand, the files on GitHub are simply newer and I can safely use them instead of the originals (and later these updates will be included in the release I guess).
Is that correct?

There has been many attempts at updating the include files. The simplest way is to curate your own Windows support and modify the INCLUDE environment variable to specify the search order - files in earlier paths will shadow those later.

Matt's includes are probably the most comprehensive set I've seen on the board. Finding a working download is challenging - I've just contested the Google Drive download (again). Google thinks it's suspicious.

Microsoft even struggles with Win32 programming language projections. I've done some work on translating the metadata. My windows development is primarily the leading edge of 64-bit. Additionally, I have a style of coding that isn't common or compatible. So, my includes aren't useful in a general way.

Many other's have put work into include sets: ProMiNick, ... hopefully they'll comment on their ongoing work, or perhaps search the board.

IMO keeping a local version of your own includes in a better option.

A convenient way to manage updates is to use a SCM. Git and Fossil are both free and open source,

Thank you!
As far as I understand, the optimal solution would be to create your own separate independent INCLUDE folder with inc files (for example, dynamically generated by the dll2inc utility) and place it first in the "include" envvar.

And what about the question about the github repository, is this an official, more up-to-date version, or a specialized independent project?

BTW Are there any more up-to-date tools (than the old python script here on the forum) to convert Windows SDK header files for fasm (I especially interested in converting WDK structures)

The problem with broad Windows support is multi-faceted (as you might know). Not just the 32/64-bit duality, but A/W string (triality ) and then throughout the branches of the Windows versions - a real mess.
Tomasz Grysztar's uses the Fossil repo for development and then forwards to the github as needed. fasmg's Windows support is largely focused on its need with some additional compatibility with fasm, afaict.

The fasm compatibility package for fasmg is no longer developed, although I still push some small fixes from time to time. But my focus moved entirely to fasm 2, which provides even more compatibility and more options.

As for the basic x86 encoder that comes with fasmg's core distribution (mirrored at https://github.com/tgrysztar/fasmg/tree/master/core/), it is the simplest implementation, intended to serve as an example of implemeting a complex instruction set, and also capable of providing fasmg's self-hosting. This simpler version is faster than x86-2, so you might prefer to use it if you want quicker assembly - although you might be better off with fasm 1 then, anyway.

That's why there are three different official x86 packages for fasmg. But only one, fasm2, I plan to develop further.