Dynamics 365 REST API implementation changed for _workerid_value

I just noticed one little finicky change to the MSDYN365 REST API.
We have two custom buttons on the case form in one of our customer solutions

1. Pick case: Lets you pick the case if it is in a queue and you are not the owner
2. Release case: Lets you release the case back into the queue if you are the owner

So I do the following query against the MSDYN365 REST api through JS (I know, I know, there's other ways to do this, but this has the lowest latency cost):

>xhr.open("GET", apiUrl + "incidents(" + caseId + ")?$select=title&$expand=Incident_QueueItem($select=queueitemid,_workerid_value)", true);

Back in the old days of version 8.0CRM2016 if there was no worker assigned to the queue item, then this would be the case:

>JSON.parse(xhr.response).Incident_QueueItem[0]._wokerid_value

undefined

But in the modern days of version 8.2MSDYN365 if there is no worker assigned to the queue item, then it would return this:

>JSON.parse(xhr.response).Incident_QueueItem[0]._wokerid_value

null

Having hacked this together in a hurry, someone (fingers crossed it wasn't me) decided to do the following check:

>if (queueItem._workerid_value !== null) { ... }

Which worked perfectly, until recently when we upgraded to MSDYN365. Now it returned true all the time, even when there was no worker assigned. The only thing that tipped us off was that it was still working in an old environment still running 8.0, so that's how we found out about it.
The workaround is, as you might already see, very simple. Just do an empty check instead of value specific check, which works for both null and undefined:

>if (queueItem._workerid_value) { ... }

Lesson learned: Implementation will change, so make (doubly) sure to plan accordingly.
EDIT: This apparently only happens for _workerid_value, so there seemed to be a mistake in the 8.0 implementation in CRM2016.
Also, to be more specific, I'm using api/data/8.0 in both examples.