In D9350#6, @epriestley wrote:

This destruction is strictly better than bin/repository delete since it automatically cleans up common linked infrastructure, so let's get rid of the old thing:

• Remove bin/repository delete (or leave it alive with a deprecation message).
• Change the UI hint about bin/repository delete to point here instead (there's a dialog that pops when you try to delete from the web UI).

I think I'm missing something here... how is this method better? It is basically just calling the same $this->delete() function? Does PhabricatorDestructionEngine handle delete transaction and edges related to the deleted object?

I did notice this TODO comment in the PhabricatorLiskDAO class:

public function delete() {

  // TODO: We should make some reasonable effort to destroy related
  // infrastructure objects here, like edges, transactions, custom field
  // storage, flags, Phrequent tracking, tokens, etc. This doesn't need to
  // be exhaustive, but we can get a lot of it pretty easily.

  return parent::delete();
}

Is this TODO still relevant if the PhabricatorDestructionEngine does this stuff? (I had started to work on implementing this TODO, but can abandon that if it is no longer required)

PhabricatorDestructionEngine handles that stuff, yes (and some level of logging, too). It doesn't handle everything yet, but does do Transactions and Edges. There are a couple of TODOs about other infrastructure systems.

The LiskDAO comment is obsolete with the advent of PhabricatorDestructionEngine. If you have work on subsystems not covered by the existing DestructionEngine code (for instance, it doesn't do tokens), that stuff can move there.