Multi-purpose columns

I have run across a real doozie of a db design that I just have to share. It is an OLTP database but it starts with the notion that there are no updates or deletes. Everything is an Insert. If a change is made to an existing row a new one is inserted that has all the data from the previous one and of coarse the changes. This means that the table no longer can use the proper PK (ID column) and includes an identity column for the PK (Key column). So now there are views everywhere so that when ever you access the table it runs a sub-query to determine which is the most recent row for that ID and assumes it is the one you want. That wasn't enough for this designer they couldn't stop there:). There is another column in the table that normally holds a FK to another table as the name implies (xxx_ID). Yesterday I found out that in reality that this column can hold the ID from one of at least 3 different tables. Sort of a multi-purpose feature I guess. Pretty slick right. Now it requires logic to determine which referenced tables you are dealing with at any time and join on the correct one. The process hsould be pattented.  OK but they didn't stop there either. It turns out that in these views that determine the correct rows they join this table with the related table. The problem is that in some cases they join using the ID column and others the Key column. So apparently depending on which side of the bed you got up on, what time of day it is etc. you join on one of several columns in several tables to the same column in this table. It must have all been part of a master plan to retire off the maintenance of this app due to the hourly vs. fixed rate:)