bootcode incompliant with DHCP RFC2131 - DISCOVER & OFFER but no REQUEST or ACK

Start with bootcode.bin, the attached packet capture, and RFC 2131 sections 3.1.3 and 3.1.4; compare the observed DHCPDISCOVER/DHCPOFFER exchange with the required sequence. Done means the netboot flow sends DHCPREQUEST, waits for DHCPACK or DHCPNAK, and only then contacts the TFTP server.

Describe the bug
Netbootcode in bootcode.bin is not behaving in an RFC 2131-compliant manner when booting BOOTP/PXE.

1. A DHCPDISCOVER is sent by RPi.
2. A DHCPOFFERs are collected. Once the one carrying SIADDR and/or(?) Option 66 containing TFTP reference has been observed RPi netbootcode stops following any semblance of prescribed procedure, configures the offered IP address and goes for the TFTP server.

To reproduce

1. Place latest bootcode.bin on the SD card.
2. Configure DHCP with TFTP options.
3. Launch tcpdump/wireshark on DHCP server or anywhere on the network (DISCOVER, OFFER and REQUEST are all broadcasts) and observe captured traffic.
4. Run the RPi on.

Expected behaviour
RFC2131 Section 3.1.3 and 3.1.4 clearly mandate what should happen next:

1. RPI netbootcode should consume a DHCPOFFER and send a DHCPREQUEST to the server that produced it to actually request that IP from the server.
2. The server in turn will reply with DHCPACK confirming IP selection or DHCPNAK if the previously offered IP has been allocated.
3. Then and only then, should netbootcode actually go for TFTP server having received confirmation it can use the offered IP.

Actual behaviour
Without confirming with the DHCP that offered it the requested configuration, RPi netbootcode uses the IP offered. Problem is, in a busy environment this may result in conflicts, offer thrashing and mess on the network where offered IPs are reused and doubly allocated.

System

• Which model of Raspberry Pi?
  Pi3B+, Pi2Bv1.1
• Which OS and version (cat /etc/rpi-issue)?
  bootcode.bin https://github.com/raspberrypi/firmware/blob/a6496ae5cd5e9b4cd5b38f7274fa94dce315fa7a/boot/bootcode.bin
• Which firmware version (vcgencmd version)?
  N/A
• Which kernel version (uname -a)?
  N/A

Logs
Attached.

Additional context
None.