Thank you all for reading, and for your comments.
For sismb8 & others:
Perhaps I should have emphasised this more: the existing security architecture in SQL Server is "dual-level" in name & feel only. Remember from the first section of my article that there is a 1-to-1 mapping between logins and users. So they are effectively (or logically) the same entities (except for the new "contained" DB users). In fact, a DB user's SID in the DB is the same as the SID of the login to which it's mapped.
And here's something I sort-of edited out of the DB-User History "note" for brevity ...
In SQL Server 2000, there was the option to include an alias to be used in the database for a login when issuing the sp_grantdbaccess command. Without it, the "user" name was the same as the login name. But either way, the username was just a label in the DB for the login. So it was the same as in 2005+, under the hood. The only difference between then and now is that the command set for managing this has changed. The alias, e.g., is now the user_name parameter of the CREATE USER command.
For mauriciorpp, Megan, others:
I think all would agree that the one-instance-one-database concept is silly.
But I think it would be helpful to remember that data and principals are separate... Do what's best to contain data, and do what's best to secure them. But do (and think of) them independently, because they're so different.
(... Sismb8, having multiple DBs in an instance doesn't require dual-level authentication, neither in theory nor practice. See MySQL for a working example. Also re-check my article sections on Security Methods & Security Summary for theoretical detail...)
And I think this difference is where you lost track with my article. I don't propose that permissions disappear from a database just because users do. Under the hood, there would still be the same/similar permissions tables in user (and system) databases. It's just that the SIDs recorded in them wouldn't reference DB users.
As for restores & attaches, that's where a robust security tool, which I mentioned in the article, comes into play. The GUI should have a tool that apportions most of the workload where it belongs--in the software:
You: Restore a DB.
Tool: "Ok. I see you have a bunch of SIDs (for server logins) in that DB that aren't on this server. Would you like me to create them for you (I'll need your help a little)?"
You: "Why yes, thank you. But some are for Windows Authentication logins from a different domain. Here are credentials for fetching those. I'll have the sysadmin create them in this domain in a minute."
Tool: "Ok. I'll see what I can find. One moment..."
. . . etc.
The lack of such a tool is a huge complaint of mine. Look at how sophisticated the tools are for clustering or replication, or file synchronization on any platform. So why are security tools treated like such an afterthought, or the runt of the litter? It just puts the load on 100,000 DBAs, year after year, instead of on a couple of programmers at Microsoft for a few months.
A flat userspace wouldn't alter the handling of encrypted data. You would still need the password/key/certificate to decrypt it, regardless of how it's transported.
Backward compatibility is a good point, and one I didn't address. But I think this would be a small factor in the grand scheme of things. A flat userspace wouldn't change an application's use of (SQL Authentication) application roles. And it wouldn't affect Windows Authentication, by definition. The work would come in refactoring apps that get in and muck about with database users and rely on ownership chaining, the TRUSTWORTHY property, etc. They'd have to point to different principals sometimes. But it's never wise to hang on to bad design for the sake of intransigence. And the corollary--hanging on to good (enough) design--hasn't stopped Microsoft from axing things before ;-).