It’s necessary to be careful when paraphrasing what someone else has said.
It does appear that the Chirpstack developer is on record as stating the (quite unusual) viewpoint that in his belief it would be architecturally preferable to enforce duty cycle at the gateway level, and not at the network server level. Mostly he says this when people file bug reports about the fact that his network server (where the standard architecture would place that function) doesn’t do so. It’s an unusual viewpoint though, as the whole architecture of LoRaWAN tries to keep the gateway functionality to very minimal translation, with all of the real protocol as a conversation between the nodes and servers - in such an architecture the gateway is only asked to implement functionality that could not be viably implemented anywhere else.
But even if for sake of argument one shares his belief as to what would be preferable, he is no doubt aware that this is not standard behavior and not offered by current gateways. If you look at the reference implementations for packet forwarders from Semtech, you won’t find duty cycle limited there. In fact even if you look at Chirpstack’s own “Concentratord” project you will see that such a thing exists only as a future planned feature - not a current one!.
thus they’re just pushing the packets sequentially to the gateway expecting that exactly the gateway will take care of delaying the packets to enforce/conform the DC.
Given that they well know that gateways don’t behave that way, this seems to be a miss-paraphrasing of whatever was actually said. But to be clear: such a strategy would be unworkable with standard gateways running standard software.
I got you right, that the packet forwarder in the RAK5278 is not delaying/buffering any packets, but just airing them, as soon as they arrive in the gateway from the network server?
To figure out what is actually going on, you’d have to look at the content actual downlink requests being pushed towards the gateways. If that’s in immediate mode, it would be sent as soon as the gateway was done; if it’s in more typical timestamp mode it would be sent at the programmed time, or dropped if the gateway is still busy with a previous packet at that time.
It’s also important to keep in mind that traditional gateways can’t even queue packets at all - if they get more than one future downlink request, they simply drop it. More recent versions of the Semtech reference implementation (on which I believe the RAK builds are closely based) do implement a queue of limited size, but still not duty cycle. And pushing too many packets too far ahead of reality would overflow the queue.
So, in my opinion, this is no pure Chirpstack issue, I want to find out, what the exact and to be expected behavior of each component is.
If the things you have paraphrased are actually the case, then this would be purely A Chirpstack issue, as it come down to expecting non-standard behavior from standard components.