1)  import lang/guile16 which is guile-1.6.x installed in
  ${LOCALBASE}/guile/1.6/ like how lang/guile14 is done now.

  2)  blindly point all the packages which currently use guile to
  lang/guile16 and bump their PKGREVISIONS.

  3)  update lang/guile to 1.8.1.

  4)  ask maintainers of the packages touched in #2 to migrate back to
  lang/guile where possible.

That sounds fine, and thanks for doing this.

I believe that executing your plan and the pending removal of guile14
once all guile14-depending packages have been updated to at least
guile16 are entirely separate issues and that there's no need to combine
them.  (You didn't say that, but it came to mind.)


The difficulty that we'll encounter in your plan is that there are
packages like guile-slib, guile-gtk, g-wrap, and maybe guile-lib that
can be built with either 1.6 or 1.8 and some packages will depend on
them.  In an ideal world with infinite resources we'd have a way like
python does to build for various guile versions and have named packages
guile14-slib, guile16-slib, and guile18-slib.  But this is a lot of
work.

Does your guile 1.8.1 package work with slib?  If it does, it might be
better (given limited cycles) to skip step (2) of your plan and then
point whatever fails back at guile16.  This breaks the build of some
packages briefly but gets us forward faster.  guile 1.8 has been out for
a long time, so an upstream package that doesn't work with it is crufty.

The only package that I know of (that isn't partially dead anyway) that
I expect to have trouble is guile-pg, because it depends on guile 1.4
compat code in 1.6 that I think has been removed in 1.8.