There is a popular UserVoice suggestion on this topic that you can vote for here. Beyond just being reticent to delete our clients' data, there are a lot of complexities with doing something like this. For instance, let's say the character "®" is used to indicate that data should be deleted. Let's also say that the field that is being removed is one used to match up to an existing record of some sort, like graduation year in an education relationship:
So if an existing education relationship is Ohio Wesleyan University, Grad year: 1999 and a user imports an education relationship of Ohio Wesleyan University with the "®" character in the Grad year, should IOM assume that is a match and delete the graduation date? Or should it treat it as not a match because it did not match on year value and add a new education relationship? What should IOM do if there are two existing education relationships with Ohio Wesleyan University with different graduation years?
So this is just one example of why it's not so easy to start deleting fields. However, I would strongly encourage you to upgrade your IOM anyway, we have added a LOT of functionality (and I'm sure some important fixes!) since version 1.9.2.
Regarding constituent codes, and this may start some philosophical debate among the RE gurus on this forum, would you consider having a separate constituent code for each separate stint a student has spent at your institution? If someone graduated with a bachelors in 1994 and got their MBA in 2002, would you want a "Student" constituent code with the dates 1990-2002?
Thanks for your feedback Kirk!