The original limits appear to be for units available for export, but I would guess manufacturers didn't want to deal with the headache of producing different models for import/export and just slapped the restriction down on everything. The poster does claim the original restriction was indeed an OR[1].
And current restrictions may only be 600 m/s? [2]pg 58
[0]https://space.stackexchange.com/questions/14687/current-situ...
[1]https://www.ngs.noaa.gov/corbin/class_description/5700-5800V...
"Immediate access to satellite measurements and navigation results is disabled when the receiver’s velocity is computed to be greater than 1000 knots, or its altitude is computed to be above 18,000 meters. The receiver continuously resets until the COCOM situation is cleared."
[2]http://mtcr.info/wordpress/wp-content/uploads/2017/07/MTCR-T...
That kind of limit is implemented in firmware (all the math is done in software), and they aren't generally protected beyond being an obscure architecture. When you've decided whatever vliw dsp architecture they use, finding a simple 'if' condition near the output logic is quite easy.
Some will even switch of the radio once one of these limits are reached and not enable it until it's been reset so make them a pain to use for even if you just wanted the location data after your payload comes back down within the limits.
EDIT: But yeah the so-called COCOM limits still apply to civilian equipment (esp to a company such as Broadcom). Unsure on the regulations for modifying the firmware on a device that doesn't put these lockouts at the silicon layer. For example: https://github.com/swift-nav/libswiftnav/blob/master/src/pvt...