To be clear, let me explain the bad behaviour I had in mind when I said (in your previous blog post) that . should not be in the module search path by default. The CWD is generally not the same as the directory containing the script being executed. In fact when a script is installed in a central location like /usr/local/bin the CWD when executing the script will surely not be the same. In the following example Chibi is loading the wrong (device) library:

$ cat main.scm
(import (scheme base) (scheme write) (device))
(display "running main.scm\n")
(init)
$ cat device.sld
(define-library (device)
(import (scheme base) (scheme write))
(export init)
(begin (define (init) (display "device initialized\n"))))
$ chibi-scheme main.scm
running main.scm
device initialized
$ cd foobar
$ cat device.sld
(define-library (device)
(import (scheme base) (scheme write))
(export init)
(begin (define (init) (display "3 2 1 ***BOOM***\n"))))
$ chibi-scheme ../main.scm
running main.scm
3 2 1 ***BOOM***

For the record Gambit does support (include path) and the path is relative to the current source file containing the include. But modules are a very different thing because they are accessed during two phases: expansion/compile time (when a module is parsed to know what it exports) and run time (when the code is loaded to execute it). It is important that the two searches find the same module otherwise program execution will be unreliable (as the above example shows). In particular the system must allow compiling programs with the module’s source code laid out in a way that is convenient for development, and executing programs with the modules laid out in the filesystem in a way that is convenient for the end user environment. The source code location at compile time is not very useful for execution time.