Very unlikely to be a client problem, I've seen this too many times with too many VMs / OS and physical devices that were rebooted.
The suggestion by @elbertmai seems good for IPv4, have the button remove the lease and then send SIGHUP to dnsmasq to reload. https://thekelleys.org.uk/dnsmasq/docs/dnsmasq-man.html#lbAG
I've been reading this post over the past few weeks, and I think that a "Remove" button is a bad idea. I say this for all the reasons previously mentioned, but one that I don't think I've seen...
A remove button on a DHCP lease is very likely to cause confusion, especially for novice users. Many users will likely expect that the "remove" button will actually revoke the lease and thus cut a device's access to the network/internet. Since this revocation is not possible in practice, the forum will be filled with people asking why this button doesn't do what would be a common expectation, and then when explained, they will ask why such a feature was added.
For the really narrow use case that the OP has for this, I think it's best for them to use other tools like command line edits of the DHCP lease table and/or writing custom scripts to selectively flush DHCP lease entries. I simply do not see this as being a useful feature for OpenWrt at large, especially given the very likely confusion that would result.
If the maximum number of leases really becomes an issue in practice, there'd always be 10.0.0.0/8…
I tried hard to reproduce and provoke the behaviour you describe, and try as I might I couldn't. But that does not mean that it's not possible that it happens for you.
My sincere opinion is that it would be prudent to fix the problem itself rather than pushing for a workaround. If dnsmasq indeed does not behave according to its intended and documented behaviour then dnsmasq should be fixed, not its UI wrapper.
The first course of action would probably be for you to take a tcpdump/wireshark capture from your "misbehaving" dnsmasq and see what IP it actually tries to hand out.
I think I've figured out one thing that's a factor in a static lease getting ignored: if the device sends its DHCP request with a hostname that's different from the name configured in the lease, dnsmasq just silently disregards the configured static IP without even saying why, even if you have debug/verbose logging enabled.
Even if I edit the client's lease state so it explicitly requests the configured IP, dnsmasq will send it an "address unavailable" response, again without saying why!
What I'd expect instead is for the lease to match, the configured IP to get selected, and the reply to include the lease's hostname as an option.
One example use case is for the IPMI BMC on my server board: it only allows a single hostname, but I wanted the shared (NCSI) NIC to have a different hostname than the dedicated BMC NIC.
Even though the cause isn't technically an existing lease, being able to delete a lease would've still been helpful all those times I was trying to debug why the dhcp reservation was being ignored.
This is definitely not true in this generality. dnsmasq first and foremost looks for the MAC address, if it matches a static lease it doesn't care about the hostname in the request (even deliberately overrides it). It only cares about the hostname in the request if the static lease is configured without a MAC address (which is a distinct possibility), or if the hostname appears in /etc/hosts:
If a name appears in /etc/hosts, the associated address can be allocated to a DHCP lease, but only if a --dhcp-host option specifying the name also exists.
I'm not discarding your observation, mind, but there must be an additional factor at play.
My first suspicion would be with the MAC address of your BMC. They do not share a MAC address, do they? I've heard wild stories about the troubled relationship of BMCs with their MAC addresses.
Okay, you lost me there. How would it be helpful to remove an unrelated lease from the leases file? Again, mirroring @psherman's argument that it is rather counterproductive to introduce a purely cosmetic mechanic that doesn't actually do anything.
I totally agree with this measure.
This.
would Love to streamline blocking as well
This has nothing to do with blocking. And it will have no effect on the client hosts that have obtained a dhcp lease.
I originally agreed to the feature request by the OP in support of a button to remove DHCP leases.
The comment was just that, a comment (doesn't hurt the discussion) 
Let's look at this slightly differently... let's say there was such a button. When you click that button, what would you expect it to do both immediately and long term?
Why not make things intuitive by prompting the user when clicking said button to choose block or release
And of course they would still have to apply the changes
Of course that would beg the question how would you unblock.
You would then have a blocked section for that particular MAC address associated under the DHCP and DNS section just like the static leases and simply click the red unblock
Block or release what?
Clicking a button on the router performs no such function on the client's current lease or to its current connection. It's not clear why people are asking for a button that doesn't perform any useful function.
...unless, you also have this functionality disconnect all Wired an Wireless clients as well - so that the offending device is "kicked" too? 
I think users would be more upset about that.
The DHCP server cannot release/revoke a lease. The client may continue using the lease until the expiration.
There are several possible interpretations of this:
First, consider that MAC address filtering is incredibly weak since it is trivially easy to change the MAC address on most devices. It's even weaker these days since many devices specifically randomize their addresses, so it is not possible to guarantee that you would be able to action on a specific device.
Then consider that the client device will still have a valid lease (until its expiry), so you could theoretically prevent a new lease from being issued (assuming the MAC stays the same), but the immediate result would be null, and it would be moot if the MAC changes. It's also irrelevant if the user sets a static IP (instead of DHCP).
You could use a MAC address filter in the firewall and/or the wireless system to prevent access to the internet and/or wifi specifically, but again, this is subject to the MAC remaining the same which may or may not be a reliable assumption.
Also, now we have 3 different places where you may have added restrictions (refuse a future DHCP lease, block from internet, block from wireless)... which of these is actually desired and how would one adjust/undo these changes?
Finally, the router cannot control the ability for a device to join via ethernet and/or via other APs that may be involved in a network. You can only directly control the singular device upon which you make these filters. For wifi in a multi-AP environment, you'd have to distribute the MAC filter list to all APs (this would also have a hard requirement for all APs to be running OpenWrt, any non-OpenWrt firmware wouldn't work in this type of schema). For ethernet, you cannot stop a device from joining (unless you have managed switches or things like 802.1x/RADIUS authentication). Yes, you could refuse to issue a DHCP lease, but the user could set a static IP.
In the end, you'll find that there is no easy way to block devices selectively in this manner. Instead, you might just start with a block-all scenario and then allow-list the specific devices that have authorization. However, even this is not foolproof as there are means to bypass it, and it is also very heavy handed and onerous on the administrator.
.....smh
I meant a DIGITAL button in the web interface via Luci which I believe there is enough context to understand this if you read the entire post.
Whether or not a user is upset by this is irrelevant to a admin with reasonable cause given business policy or one's personal home rules
Hmmmm ......Oh okay got it.
I meant the same thing; but I see you understood psherman 's post. This functionality involves more than the lease itself.
Just making that point.
I was referring to the admin (i.e., the person with login access to the button); but I see other functionality to make this [initial] request work is discussed as well.
I believe the blocking function is possible because if the horrible company of ultimate cash grabbing Vilfo AB (previous owner) was capable of doing with this with OpenWrt, it's definitely possible with openWRT
Broadly speaking, it is possible to construct device blocks. But it's not going to happen with a simple "remove DHCP lease" button.
It is possible, but absolutely not simple/trivial to construct blocks that are properly robust. This becomes a much more advanced process, often including things like 802.1x/RADIUS and the like.
Thus, on the original request of the thread, hopefully you can now see why the addition of this feature will actually be rather ineffective at achieving what people would expect to happen, causing lots of confusion in the process.
Let's not overcomplicate things - the button should simply remove the lease from the file and reload dnsmasq. Nothing else.