Simplify the flow for deleting rules/data elements/extensions in Launch - Status changed to: Accepted

[#1]

The flow for deleting changes in Launch feels a bit overly complicated, especially for changes that only currently exist in one dev library.

First, I get this prompt:

But if I say yes, I then get this prompt:

Then I have to go to the library, find that specific change/revision, and unselect it.

At bare minimum, it'd be nice to not get the first prompt asking if I want to delete it if, in fact, I can't delete it. Or, if I get the "delete failed prompt" instead of sending me along to the library to find the change, it gave me the option to disable and delete it right there.
But generally, if I am trying to delete something, it's because I want it to be disabled and removed. I know it's in use by a library, that's what I'm trying to solve for. It would be great if the deletion flow more closely resembled DTM- a deletion counts as a change that needs approval, etc, just like addition/editing changes.

[#2]

I agree that having a deletion be a change that needs to be published like any other change would be the simplest way to manage that.  The technical guts of accomplishing that (states of being marked for deletion without actually being deleted) is more than what we wanted to take on for a first phase.  There are a lot of these workflows that are functional, but could be made a lot better when we can make the time.

[#3]

I agree with Jenn. It would be nice if the deleted rules showed up in a library as well rather than just have the deleted rule disappear from Launch with no trace of when it was deleted. This would make troubleshooting much easier. Often in DTM we will use the publishing history to track down exactly when a certain rule deletion was published and this is something that you cannot currently do in Launch.