Guile foreign object interface

[Mike Gran]

Hi All-
I wanted to make a quick post about the foreign object interface.
This is a bit of a placeholder because I haven't had time to
investigate the interface properly, yet. But I intend to poke at
it soon.
But for there record, there are some problematic design patterns
that I want to make sure can be covered by the new interface.
Again, I'll try to make proper examples soon, but, with Andy wanting
to release soon, I want to get this down now.

1. First off is a Lilypond-like pattern.  A C++ vector
is used to dynamically add or remove elements.  The memory
management of those elements lives in the C++ world.  Those elements
are boxed up as SCM.  GCing the SCM should not free its boxed
contents, but, deleting the boxed contents from the C++ side
should render those SCMs invalid in some sense. 
2. Mutually owned information. Two structures (A and B) both
mutually contain a non-GC-malloc'd structure C. C must exist
so long as one of A or B exist.
3. Here's one from guile-ncurses. An element ITEM is created with
some contents. Default memory management suffices: if ITEM is GC'd,
its contents are GC'd.  But the contents of ITEM can later be
attached to a COLLECTION. If ITEM is GC'd when attached to
COLLECTION, its contents are not GC'd.
5. Gobject-like subclassing.  In Gtk, an application window is
a type of a window which is a type of a widget which is a type of
object. If we were to resurrect an effort on GTK3 binding,
how would it work for foreign objects?
Again, forgive this random dump. Wanted to get something down now,
but I'll try to make a more sensible post later.
-Mike Gran