You don't even need to change the QR code to treat users differently, that's the point. You just send users to some fixed URL, which is by far the most common use for QR codes (hence completely unsuspicious), and you decide who gets served what there, based on whatever data you gathered about them. And the users that would care are already acutely aware that that's how a majority of the web works nowadays, QR codes or not.
The value of an attack vector is not negated by there being other ways to achieve it.
This particular vector has the strength of being able to manipulate things other than URLs; QR codes support WiFi credentials, contact details, call, text (with content), email (with content), calendar events. Additionally, many app specific URIs never leave the device.
It has the significant downside of being plainly visible as a possibility to those in the know.
However, I suspect it may still be desirable to do this on the device rather than the server.
The other properties it varies are the obvious lack of reliance on a server. The improved "transparency" of showing the target URL for trust. The removal of the need for an internet connection.
But for an implementer I'd imagine the most beneficial upside is not needing to manage a timing-attack, and gaining additional targetting accuracy in the common case of a picture. There may also be organisational complexity reduction in pushing all the decisioning to the display/camera system.
Its fun to think about, with the significant weakness in both its visibility and its probabilistic nature I wouldn't expect widespread use.
Static Qr-Code but serve different content? If you are targeting by the camera, you can try to link the person to the time the QrCode was scanned and have each QrCode print identified.
