+** Evaluation of "()", the empty list, is now an error.
+
+Previously, the expression "()" evaluated to the empty list. This has
+been changed to signal a "missing expression" error. The correct way
+to write the empty list as a literal constant is to use quote: "'()".
+
+** New concept of `Guile Extensions'.
+
+A Guile Extension is just a ordinary shared library that can be linked
+at run-time. We found it advantageous to give this simple concept a
+dedicated name to distinguish the issues related to shared libraries
+from the issues related to the module system.
+
+*** New function: load-extension
+
+Executing (load-extension lib init) is mostly equivalent to
+
+ (dynamic-call init (dynamic-link lib))
+
+except when scm_register_extension has been called previously.
+Whenever appropriate, you should use `load-extension' instead of
+dynamic-link and dynamic-call.
+
+*** New C function: scm_c_register_extension
+
+This function registers a initialization function for use by
+`load-extension'. Use it when you don't want specific extensions to
+be loaded as shared libraries (for example on platforms that don't
+support dynamic linking).
+
+** Auto-loading of compiled-code modules is deprecated.
+
+Guile used to be able to automatically find and link a shared
+library to satisfy requests for a module. For example, the module
+`(foo bar)' could be implemented by placing a shared library named
+"foo/libbar.so" (or with a different extension) in a directory on the
+load path of Guile.
+
+This has been found to be too tricky, and is no longer supported. The
+shared libraries are now called "extensions". You should now write a
+small Scheme file that calls `load-extension' to load the shared
+library and initialize it explicitely.
+
+The shared libraries themselves should be installed in the usual
+places for shared libraries, with names like "libguile-foo-bar".
+
+For example, place this into a file "foo/bar.scm"
+
+ (define-module (foo bar))
+
+ (load-extension "libguile-foo-bar" "foobar_init")
+
+** Backward incompatible change: eval EXP ENVIRONMENT-SPECIFIER
+
+`eval' is now R5RS, that is it takes two arguments.
+The second argument is an environment specifier, i.e. either
+
+ (scheme-report-environment 5)
+ (null-environment 5)
+ (interaction-environment)
+
+or
+
+ any module.
+
+** The module system has been made more disciplined.
+
+The function `eval' will save and restore the current module around
+the evaluation of the specified expression. While this expression is
+evaluated, `(current-module)' will now return the right module, which
+is the module specified as the second argument to `eval'.
+
+A consequence of this change is that `eval' is not particularly
+useful when you want allow the evaluated code to change what module is
+designated as the current module and have this change persist from one
+call to `eval' to the next. The read-eval-print-loop is an example
+where `eval' is now inadequate. To compensate, there is a new
+function `primitive-eval' that does not take a module specifier and
+that does not save/restore the current module. You should use this
+function together with `set-current-module', `current-module', etc
+when you want to have more control over the state that is carried from
+one eval to the next.
+
+Additionally, it has been made sure that forms that are evaluated at
+the top level are always evaluated with respect to the current module.
+Previously, subforms of top-level forms such as `begin', `case',
+etc. did not respect changes to the current module although these
+subforms are at the top-level as well.
+
+To prevent strange behavior, the forms `define-module',
+`use-modules', `use-syntax', and `export' have been restricted to only
+work on the top level. The forms `define-public' and
+`defmacro-public' only export the new binding on the top level. They
+behave just like `define' and `defmacro', respectively, when they are
+used in a lexical environment.
+
+** The semantics of guardians have changed.
+
+The changes are for the most part compatible. An important criterion
+was to keep the typical usage of guardians as simple as before, but to
+make the semantics safer and (as a result) more useful.
+
+*** All objects returned from guardians are now properly alive.
+
+It is now guaranteed that any object referenced by an object returned
+from a guardian is alive. It's now impossible for a guardian to
+return a "contained" object before its "containing" object.
+
+One incompatible (but probably not very important) change resulting
+from this is that it is no longer possible to guard objects that
+indirectly reference themselves (i.e. are parts of cycles). If you do
+so accidentally, you'll get a warning.
+
+*** There are now two types of guardians: greedy and sharing.
+
+If you call (make-guardian #t) or just (make-guardian), you'll get a
+greedy guardian, and for (make-guardian #f) a sharing guardian.
+
+Greedy guardians are the default because they are more "defensive".
+You can only greedily guard an object once. If you guard an object
+more than once, once in a greedy guardian and the rest of times in
+sharing guardians, then it is guaranteed that the object won't be
+returned from sharing guardians as long as it is greedily guarded
+and/or alive.
+
+Guardians returned by calls to `make-guardian' can now take one more
+optional parameter, which says whether to throw an error in case an
+attempt is made to greedily guard an object that is already greedily
+guarded. The default is true, i.e. throw an error. If the parameter
+is false, the guardian invocation returns #t if guarding was
+successful and #f if it wasn't.
+
+Also, since greedy guarding is, in effect, a side-effecting operation
+on objects, a new function is introduced: `destroy-guardian!'.
+Invoking this function on a guardian renders it unoperative and, if
+the guardian is greedy, clears the "greedily guarded" property of the
+objects that were guarded by it, thus undoing the side effect.
+
+Note that all this hair is hardly very important, since guardian
+objects are usually permanent.
+
+** Continuations created by call-with-current-continuation now accept
+any number of arguments, as required by R5RS.
+
+** New function `issue-deprecation-warning'
+
+This function is used to display the deprecation messages that are
+controlled by GUILE_WARN_DEPRECATION as explained in the README.
+
+ (define (id x)
+ (issue-deprecation-warning "`id' is deprecated. Use `identity' instead.")
+ (identity x))
+
+ guile> (id 1)
+ ;; `id' is deprecated. Use `identity' instead.
+ 1
+ guile> (id 1)
+ 1
+
+** New syntax `begin-deprecated'
+
+When deprecated features are included (as determined by the configure
+option --enable-deprecated), `begin-deprecated' is identical to
+`begin'. When deprecated features are excluded, it always evaluates
+to `#f', ignoring the body forms.