1. It is rare that guix home import does the right thing (it is usually removing some startup file customizations, does not seem to arrange to pick up profiles, not even its own). Either we should improve it, or document that it only gives a skeleton configuration and add some guidance on the steps needed to get a working one.

2. The user default profile and the home package profile being separate is causing some issues. It might be enough to document all the special profiles somewhere (which as of now include at least system profile, user profile, pull profile and home profile), but we can also think about a bit more general solution, along the lines of a home service that ensures that a given profile matches the supplied manifest, and have variables for the special profiles. (These could then provide extensions to the shell services which could arrange to pick them up)

3. Sometime on home reconfigure the shell prompt customizations seem to get lost. Sourcing the shell startup file fixes it. I will have to look into this more to file a proper bug report.

4. Creating a guix development environment service would be beneficial, to showcase the possibilities and to simplify onboarding. On top of there could be an additional service that adds emacs integration to this development environment.

5. There was a recommendation to relax the expectations on the home services merged. Right now a lot of people are just writing services for private use. Most probably such a single usecase service would already be beneficial to multiple people. The idea is the following: make it easy for an initial home service to be merged. (Example: do not ask to implement options that the submitter is not using). Then take care that if there is an addition to the service that it really gets merged with what we already have. This needs a bit of up front design, we have to make sure that the services can be extended while maintaining backwards compatibility.