I've pushed all patches except those concerning strict byte compilation,
emacs-scel, emacs-org-contrib, emacs-howm and emacs-calfw.

Some comments follow.

> Done, although match-let appears to be undocumented :/.

Yes, match-let is currently undocumented. But, I have a pending patch to
guile regarding this. So, hopefully, this will be fixed soon.

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=30144

> In the past I played with attempting to define a
> search-path-specification for our Emacs package, which would
> generalize even more the way our Emacs packages are discovered in
> Guix. That ended up looking like the following:
>
> --8<---------------cut here---------------start------------->8---
> +    (native-search-paths
> +     (list (search-path-specification
> +            (variable "EMACSLOADPATH")
> +            (files '("share/emacs/site-lisp"))
> +            (file-pattern ".*")
> +            (append-separator? #t))))))
> --8<---------------cut here---------------end--------------->8---
>
> Where the new "append-separator?" argument was added by myself (this is
> a world rebuilding change and also changes the manifest file). I didn't
> pursue that for now given that it still suffers from 1. explained above.
>
> The nice properties of this however was that it was now possible to have
> the Emacs dependencies found in `guix environment' as well as in the
> build system (anywhere), by using the native mechanism that Guix comes
> with. If you have interest in going that way I could revive those two
> old patches.

For now, I've pushed with the set-emacs-load-path function you
provided. But, you could pursue this world rebuilding search-paths
approach as a separate bug report.

>>> Subject: [PATCH 15/27] gnu: Add emacs-scel.
>>>
>>> +(define-public emacs-scel
>>> +  (let ((version "20170629")
>>> +        (revision "1")
>>> +        (commit "aeea3ad4be9306d14c3a734a4ff54fee10ac135b"))
>>> +    (package
>>> +      (name "emacs-scel")
>>> +      (version (git-version version revision commit))
>>> +      (source (origin
>>> +                (method git-fetch)
>>> +                (uri (git-reference
>>> +                      (url "https://github.com/supercollider/scel.git")
>>> +                      (commit commit)))
>>> +                (file-name (string-append name "-" version "-checkout"))
>>> +                (sha256
>>> +                 (base32
>>> +                  "0jvmzs1lsjyndqshhii2y4mnr3wghai26i3p75453zrpxpg0zvvw"))))
>>> +      (build-system emacs-build-system)
>>
>> This package seems to use a cmake-build-system. Did you try that?
>
> I didn't, on purpose. I wanted the Elisp files to be processed the same
> as most of our other Emacs packages (with the patch-el-files phase
> patching binaries, for example) that we would miss otherwise).

I get your point. But, I think we can use phases from both the
emacs-build-system and the cmake-build-system, like I have done in the
attached patch. This keeps us more in line with the upstream repo,
rather than us reinventing too much. WDYT?