Sicher, aber das ist genau der Punkt:
Der Befehl kommt aus der Anwendung. Dort wird ja explizit das Löschen aufgerufen.
Deshalb wird dafür eigentlich gar kein Event benötigt, da Events nur gebraucht werden, wenn der Programmierer etwas mitbekommen muss, von dem er sonst nicht mitbekommen würde, dass es passiert. Da die Aktion hier selbst per Quelltext gestartet wird, weiß man das aber schon.
Deshalb ist die Logik schon etwas seltsam, aber letztlich schadet ein solches Event auch nicht. Es ist nur rein logisch überflüssig.
Damit ist die Lösung, die du jetzt benutzt, schon ok, wenn auch nicht optimal.
Wenn der Anwender etwas will, dann heißt das nicht, dass das Programm das auch tut. Deshalb ist es bei einer "Vorhersage" gut möglich, dass die Anzeige vorschnell eine falsche Änderung anzeigt, diese aber aus irgendeinem Grund nicht durchgeführt werden konnte. Das kann dann zu einem Programm-, Anwendungs- oder Daten-Fehler führen. Auch ist denkbar, dass neben dem Anwender und dem Programm eine dritte Ebene (z.B. das Dateisystem oder eine Datenbank) beteiligt ist, welche wiederum in die Ausführung eingreifen kann. Aus all diesen Gründen ist es im allgemeinenn ratsam, nur mit Tatsachen zu arbeiten. Etwa bei dem Listview-Beispiel abzuwarten, bis Items.Count wirklich um die Zahl der gelöschten Items vermindert wurde. Alles andere ist unsauberer Programmierstil. Aus diesem Grund gibt es bei Datenbanken auch das Transaktions-Prinzip, um Inkonsistenzen zwischen verschiedenen Bereichen (etwa Client und Server) zu verhindern.