My note is related to @b. I understand to the motivation, but I am not sure if it is good idea. Tables and views shares one namespace.
But the command say "drop table" and so it must only be concerned with that subset of the namespace when searching. The note about the view is helpful, but it shouldn't change whether the command succeeded with a notice or errors.
Often usage of DROP TABLE IF EXISTS is together with CREATE TABLE
Now if some does bad reference in DROP TABLE command, then this command fails (first). If we do proposed change, then DROP TABLE do nothing, and CREATE TABLE fails.
Yes, this is what should be happening. CREATE does have to care about the whole namespace since it creating a new identifier.
So I am not sure, if proposed change is practical because views and tables shares same namespace and current behave has sense too.
I'm doubtful that there is any meaningful technical/practical challenge involved here. And as you say when doing paired drop/creates one of them is going to fail anyway so it doesn't really matter which one. But if someone wants to convert a table to a view imdompotently (the point if INE) right now they cannot using the features that are documented to do just that.
Just I don't see this proposal as clean win. More it is not limited only this case. It should be consistent with DROP INDEX, SEQUENCE, ...
