The data modell does not support the real world example that an organization can have the same e-mail address as an individual within this organization at the same time. Due to this constraint all applications are forced to write some code which allows them to find the best e-mail address to use. In contacts we do this for employees by using the nasty hack of saying "if e-mail empty, check for employer e-mail and use this one". Though this spells trouble for the users who work at two different organizations but have a prefered organization e-mail. Dropping the unique constraint allowed us to do exactly this.
But anyway, I will not bring up a TIP but use this in our own patch which we just don't commit (as this has proven the best way for other companies who have the need for changes and don't have the luxury of lengthy debates). Which should solve the process problem from our side as, if we accidently make a commit which you feel should be discussed, we immediately remove it and put it into a patch. No big deal. If you feel this puts an unnecessary burden on the community (as obviously I disagree with your interpretation of the TIP rules and therefore am prone for running into this conflict again and again), feel free to ask us not to commit anything to core anymore, then we at least know where we stand.
As you mentioned the issue with application data links, feel free to start a discussion on that and we will make our point why we did it this way (as we did earlier, but I don't think that a list of IRC logs and forums posting links would change your perception). If you don't like then we will just put it into a seperate package as it would be totally unfair if we put this into a patch as nearly all packages we have been working on rely on that API [yeah, I know, very *evil* and sneaky behaviour of making a core change and making sure that removing it will render 5 packages useless 😊].
