renaming+recreating table w/default sequence causes dependency seq issue

I saw issues around renaming tables and not renaming sequences in the TODO
list but did not see anything about this.  Apologies if I missed it.

This is with a 9.1.4 server (enterprisedb download on mac os/x lion) and also
seen on 9.1.3 built from netbsd pkgsrc.

It appears that something is amiss if you try to drop a table that has been
renamed that used to have a default mapping to a sequence:

Given this:
---<snip>---
drop table IF EXISTS foo;
drop table IF EXISTS foo_v26;

create table foo (id serial not null, bar integer );
alter table foo alter column id drop default;

alter table foo rename to foo_v26;

create table foo (id integer not null, bar integer );

alter table foo alter id SET DEFAULT nextval('foo_id_seq');

drop table foo_v26;
---<snip>---

everthing works as expected until the final drop, which says:

jazzhands=> drop table foo_v26;
ERROR:  cannot drop table foo_v26 because other objects depend on it
DETAIL:  default for table foo column id depends on sequence foo_id_seq
HINT:  Use DROP ... CASCADE to drop the dependent objects too.

however...

jazzhands=> \d foo;
                         Table "public.foo"
 Column |  Type   |                    Modifiers
--------+---------+--------------------------------------------------
 id     | integer | not null default nextval('foo_id_seq'::regclass)

jazzhands=> \d foo_v26;
    Table "public.foo_v26"
 Column |  Type   | Modifiers
--------+---------+-----------
 id     | integer | not null

Interestingly, I can drop table foo without any complaints.

It seems like the dependency did not move (it also seems like its
backwards but that's probably all me).

Sadly, if I move setting the default to after I drop the old table, the
sequence goes away, so I am still digging into a work around.

thanks,
-Todd