So I was fairly pissed off because I couldn't find any up-to-date guides on how exactly qubes-firewall-user-script didn't work the way I wanted most of the time so I decided to drop this post here after some personal research with tshark. Take it as a starter for whoever wants to play around with their nftables or any networking settings at all but also take it with a grain of salt because I am still one of these people that haven't yet learned ipv6 even when I have AI at my fingertips 24/7
First of all the only thing I am not completely clear about as far as I understand networking turns on AFTER qubes-firewall-user-script, if there is anything you need to research on your own is the order of services loading related to networking which I haven't really delved into that match.
There are a few things to consider, the folder /etc/qubes contains a few nft files but should not be used for firewall at all like some people would consider, so do not drop any files there for early loading as you will need to edit the bash script that loads these files and you do not know if it gets overriden at some point by an update which will cause you to leak data since your firewalls wont work.
Now on the main topic, the qubes-firewall-user-script is executed by a python script, I didn't delve into it too match but I think it would cause some mishaps to happen if you treat it as a normal #!/bin/bash like it says at the top of the file.
If you want to just write bash executable lines(i.e nft add ...) it works just fine
If you want to execute a .nft file (i.e /rw/config/my-dns-redirect.nft) it does not work and you you have to do some shell subtitution by running $(/rw/config/my-dns-redirect.nft)
I might be loosing my mind here or tshark bugged out/sys-net lagged out(I was running tshark on sys-net) but I think by the time the firewall loads there is a tiny bit of leaked data, it is not something I could honestly repeat but it happened twice in my tests and I dont know why, the solution for me is simple, i have ipv4 forwarding and ipv6 forwarding off by default and I turn them(or at least ipv4) on at the end of qubes-firewall-user-script after all nft scripts have loaded, I would also add an .nft file at the first line that links to a script that drops prerouting, output,input,forward,postrouting with priority of -300 for a good measure.
Lastly I am not sure if this is intended behavior or a bug of qubesos but if you use any inet tables at all then all your qubes downstream and upstream are populated by ipv6 addresses and your wifi and ethernet grab their own ipv6 addresses from the router, in my case I received a a dozen link-local and a couple global(not uniqe local ;( ) addresses for my discovery even if you have ipv6 off by default, I honestly almost gagged when i noticed that because at any point a compromised qube could update its nftables with an inet table and turn the whole system to an ipv4/ipv6 system, so either secure all your endpoints(sys-i2p, sys-wifi,sys-ethernet etc) with appropriate rules to enable or completely disable ipv6.
I am not even touching subjects like ip route and arp, you should know they work just fine with and without $(), to this point in more then 100 vm restarts and tests I have done I haven't noticed match problems with them, but you should know I mainly wrap all my commands inside qubes-firewall-user-script with $() just to be sure, one final note, if you use a custom sysctl as you should, you generally do not need to place it in /rw/config/rc.local as it executes on it's own if you place it anywhere in /etc/sysctl.d or /etc/sysctl.conf,nevertheless these sysctl locations load before qubs-firewall-user-script so you can perform changes in the qubes-firewall-user-script if you'd like, on the otherhand rc.local works just fine as well for the job but as far as I know it is depricated. I have not tested any kernel tracing utilities on qubes-firewall-user-script but I don't suspect they would misbehave. I think that would be all I have on my mind for qubes-firewall-user-script.
TL;DR