Sure, if your app is already designed with that feature. Many existing apps are not.

So what? Just add a column if you are using SQL, or a new ad-hoc property if you're using an unstructured document DB. Recruiting the sign but is a recipe for disaster. E.g., what happens the next time you need to add a boolean property, and the sign bit is already taken? What happens if you need...

...to add a new feature which requires a non-boolean property? You better have the ability to update your DB schema then. And what happens if the positive ID gets reassigned to another record (because hey, that value is unused!), and then you decide to undelete something?

IDs should never have any auxiliary meaning beyond being a unique ID, or you are on track to create more problems than you solved.

Just add a column...and then rewrite all of your data access code to respect this new logic. This is a ton of work!

So is rewriting all your data access code to pay attention to the sign bit!

All we are accomplishing with flipping the sign is unlinking an existing refence. That can be useful in a deployed app depending on the situation, like in production support scenarios. I would not design an app this way, but that does not mean it is not useful in existing apps

So you're not adding a feature, you're just manually screwing with the DB in a live support situation? Again, there are better ways, and the fact that this error may be useful in a particular scenario does not mean that it is necessary or a good idea.

Yep sometimes a FK row needs to be separated from the parent row. And I don't want to hard delete it. That can be really problematic if there are enforced integrity constraints. And lots of FKs directly reference parent PKs. signed int keys really help here

Then again I submit that you are doing something dangerous and unnecessary, and it is just luck that it hasn't bitten you yet.