Your question is rather strange.
If the DELETE command wasn't interrupted, then the number of remaining rows would always be zero.
I mean, if you run
DELETE FROM SomeTable
WHERE <SomeCondition>
and this command was successfully committed, then if you try to count the remaining rows with the same condition:
SELECT COUNT(*)
FROM SomeTable
WHERE <SomeCondition>
that would always return 0. (Obviously, if there are no concurrent processes that change the table values.)
If the DELETE command was interrupted, then it would roll back, then none of the rows would be deleted.
Any DELETE or UPDATE or INSERT command is atomic, either all of it is done, or none of it is done in RDBMS like Postgres.
That's why Postgres does not provide a way to return the number of remaining rows after DELETE - it is always 0.
If there are other concurrent processes that may change the table while the original DELETE runs, and they change the table in such a way that the original DELETE doesn't "see" these changes and doesn't delete them, then you should explicitly run the second SELECT COUNT(*) to get the latest count.