BUG #18081: Spurious "function with OID ###### does not exist" error

The following bug has been logged on the website:

Bug reference:      18081
Logged by:          Branko Radovanovic
Email address:      branko.radovanovic.zg@gmail.com
PostgreSQL version: 13.5
Operating system:   Debian 8.3.0
Description:

When executing the following sequence of statements:

        CREATE OR REPLACE PROCEDURE proc(param text default 'n/a')
            LANGUAGE plpgsql
        AS $procedure$
            BEGIN
                raise info 'proc(%)', param;
            END;
        $procedure$;

        CREATE OR REPLACE PROCEDURE test1()
            LANGUAGE plpgsql
        AS $procedure$
            BEGIN
                call proc();
            END;
        $procedure$;

        CREATE OR REPLACE PROCEDURE proc()
            LANGUAGE plpgsql
        AS $procedure$
            BEGIN
                raise info 'proc()';
            END;
        $procedure$;

        DROP PROCEDURE proc(text);

        CREATE OR REPLACE PROCEDURE test2()
            LANGUAGE plpgsql
        AS $procedure$
            BEGIN
                call proc();
            END;
        $procedure$;

        call test2(); --#A
        call test1(); --#B

...statement #A will output:

        proc()

...which is as expected, while statement #B will throw an error:

        SQL Error [42883]: ERROR: function with OID 102048 does not exist
          Where: SQL statement "CALL proc()"
        PL/pgSQL function test1() line 3 at CALL
        
I get this behavior in versions 13.5 and 14.9. This is strange because it
would imply that:
1) It is possible to have two procedures with identical bodies, one of which
works while the other does not
2) The way a procedure behaves is dependent on the state of the database in
the instant the procedure was created

Both of these conclusions break the mental model of plpgsql as being fully
interpreted. On top of that, this sort of situation cannot be detected by
parsing tools such as plpgsql_check nor by human review, as nothing is wrong
with the code itself. I would argue that #B should work exactly the same as
#A.

Best regards,
Branko Radovanovic