To my understanding, git for windows ships a native Windows platform binary, which can be interfaced from a bash emulation based on msys2 merely to hide platform differences.
One can also use a linux binary in WSL2, which relies on the entire WSL compatibility layer.
Are there limitations or functional differences in using git through WSL and using git for Windows through git bash to manage a git repository on a Windows 10 file system? This could pertain things as
This question is focussed on the git command line interface, not on IDEs wrapping a (possibly included) git binary.
The Git binary as shipped with a Linux distro is going to be a pretty vanilla distribution of Git. It is typically going to be configured such that using the --help option opens a manual page unless you've configured it differently, and it may or may not (depending on the distro) be configured to support the libsecret credential helper, which is standard on Linux.
Git for Windows is a distribution of Git which contains a Git with some additional features and different defaults (generally those suited to Windows), along with bash, a limited version of Perl, and many Unix tools, as well as a terminal emulator. Many of these features and defaults are designed to work better on Windows; for example, Git for Windows supports SChannel, the native Windows TLS library, and it defaults to opening manual pages in the web browser (because it doesn't ship man or roff).
Using a Linux version of Git will expect chmod and friends to be fully functional (or at least fail silently). Sometimes that works on a Windows file system in WSL, and sometimes it doesn't. You can test by running git init in a directory on your C drive and see if it pukes on running chmod(2). If it works, then that version of Git should typically work just fine; if not, then it won't for anything that involves modifying the permission of the config file (git init or git config). Linux distros will not care that WSL breaks chmod because WSL is not something they ship or are responsible for, so there isn't going to be any interest in fixing it. However, this gist may help you work through some of those issues.
As far as hooks, I believe Windows drives pretend all files have the executable bit set, so typically hooks will work just fine for a Linux Git.
The defaults for line endings may differ between a fresh installation of Git for Windows and a Linux Git. Git for Windows will prompt you to select the behaviour you want, so if you turn off core.autocrlf, then that will be the desired behaviour for compatibility. You can also simply use a .gitattributes file or set core.eol=lf in your per-user .gitconfig to always use LF endings.
For permissions, Windows file systems are not going to have the richness of permissions that Unix is. As mentioned, they mark all files as executable (although the aforementioned gist may be able to help) and if that's the case, you're going to have some trouble if you need to adjust the permissions of files. git update-index --chmod can help with that, though.
What can cause problems is using both a Windows and a Linux version of Git with the same repository. The two versions of Git store different metadata in the index and so when one of them has updated the index and you run git status in the other, it will re-read all of the files. This may be possible to avoid by setting core.trustctime to false and core.checkstat to minimal (which you should try in that order).
I don't use Windows very often, but when I do, I do use WSL in this very scenario, and it does typically work and is very functional. I use primarily WSL for development and use Git Bash to invoke Windows programs in a Unixy way. While there are some minor pain points, it is possible to do.