Yes, the example shows setting the current tenant id to all ones and then performing a select revealing a tenant id of all twos.

The same result is displayed in another example when correctly using a tenant id of all twos. A mistake perhaps of wrong output with the wording in the article is all.

somewhere only in one place there will be main index with at least references to locations where to find others. at the top somewhere there is always just a flat list. this is a multi-dimensional problem. i really want to know real life scenario someone arguing for or against this. really interested to see what side people pick and where they draw the line of what it means to be multi-tenant. personally, i will never again write multi-tenant code ever again in my life. the implementation i've modeled for myself because i understood that immediate backup and restore is more important than fancy multi-tenancy.

Even then, you do want to provide some degree of hardware-adjacent isolation to limit not just the blast radius but also computational cost of some DDL operations in a multi-tenant setup.

For example, you generally only want to have one tenant’s data per storage page. There are many famous ways that interleaving different tenants’ data at a fine-grained level can go very wrong.