[noobiemcfoob]

The problem this is addressing is a code being impenetrable by a human. If your solution is adding a second (human readable) code beneath the machine readable code...you haven't addressed the problem. The user must still trust their reader to parse the code.

QR codes' reconstructability is a major strength that this lacks, but I'd bet there's a way to expand this to include ECC around it, much as QR codes can.

BUT...OCR is quickly advancing, so the need for a specialized code a specialized machine can read will diminish over time anyway.

[gnode]

As I suggested at the end, you could still employ OCR and have a barcode checksum. The checksum would ensure a misread of the human readable text would fail. As long as the checksum was not error-correcting (so could not be engineered to augment a correct OCR read), it doesn't matter that it is incomprehensible to humans, because the OCR is authoritative.

You could also implement the checksum as OCR-able text, although it wouldn't be as dense, and probably wouldn't help human readability.

I think ultimately it should not be trusted that a machine will read what a code appears to be. That should be enforced on the device: "Are you sure you want to visit malware.site?". It's also easy to manipulate computer vision; you can engineer patterns which will read as one thing to humans, but another to machines. In some ways it's better for these codes to not be human readable, such that trust is not misplaced, and the machine is used as the best source of truth.

[ggrrhh_ta]

I can imagine that it would not take long until someone comes up with patterns which are innocent in one orientation and malicious with a ±90 deg. rotation...

[theamk]

Not with QR codes, they read the same from any side