During the upstreaming process of Guix Home commit
fee0bced7fec2f9950957976a28f033edd4f877c slipped into master.  It
introduces a different serialization approach for text-config from what
was orginally used:
https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/services/configuration.scm?h=2c451db39aabc69bdbf186f412ee6e0b4e180ccb#n386

This new approach is inconisistent with the ideas used in the number of
other home services (not only the ones using text-config):
https://git.sr.ht/~abcdw/rde/tree/47f6c65c82a4f6761fa1ff5b9405b363cfda6482/item/gnu/home-services

So I had to fork it back to avoid an inconsistency and renamed
text-config to gexp-text-config to avoid a confusion with upstreamed
version.
https://git.sr.ht/~abcdw/rde/tree/47f6c65c82a4f6761fa1ff5b9405b363cfda6482/item/gnu/home-services-utils.scm#L355

Having two serialization approaches stops me from upstreaming the rest
of home services from rde to Guix and also makes a split to rde home
services and guix home services, which I would like to avoid.

We need to decide, which approach should be used or we will end up with
two competitive incompatible implementations and unecessary split of
effort and lose of human force and time.

I wanted to solve this question as a part of
https://issues.guix.gnu.org/52698, but seems it doesn't get enough
attention (probably cause of the volume of information in the patch).

I'll provide a few technical details, which supports the original
appoarch.

Before fee0bc serialization for text-config worked this way:
--8<---------------cut here---------------start------------->8---
`("string here"
  ,#~"string valued gexp"
  "source \"
  ,(local-file "blabla.sh"))
--8<---------------cut here---------------end--------------->8---

would yeld something like:

--8<---------------cut here---------------start------------->8---
string here
string valued gexp
source \
/gnu/store/00fl96dj2aak4i1vqvdqzlhbmmskc7fx-blabla.sh
--8<---------------cut here---------------end--------------->8---


There is another less generalized example, which demonstrates how
serialization of sway configuration works right now.

--8<---------------cut here---------------start------------->8---
`((include ,(local-file "./sway/config"))
  (bindsym $mod+Ctrl+Shift+a exec
           ,(file-append emacs "/bin/emacsclient") -c --eval "'(eshell)'")
  (bindsym $mod+Ctrl+Shift+o "[class=\"IceCat\"]" kill)
  (input * ((xkb_layout us,ru)
            (xkb_variant dvorak,))))
--8<---------------cut here---------------end--------------->8---

would yield something like:

--8<---------------cut here---------------start------------->8---
include /gnu/store/408jwvh6wxxn1j85lj95fniih05gx5xj-config
bindsym $mod+Ctrl+Shift+a exec /gnu/store/...-emacsclient -c --eval '(eshell)'
bindsym $mod+Ctrl+Shift+o [class="IceCat"] kill
input * {
    xkb_layout us,ru
    xkb_variant dvorak,
}
--8<---------------cut here---------------end--------------->8---

The new text-config serialization implementation (after fee0bc commit)
doesn't support gexps and tries to insert the literal content of the
file in place where file-like object was used, which

1. Confuses the users.
People reporting that it's hard to implement something like

source \
/gnu/store/00fl96dj2aak4i1vqvdqzlhbmmskc7fx-blabla.sh

with the new approach (using file-like objects), and they switch to the
original implementation of home services for shells (the ones currently
living in rde repo), which allows to use gexps.

2. Looks strange implementation-wise.

If we want to insert the file path to file-like object for new-style
text-config internally we do something like

(mixed-text-file ...
 "source \" "\n"
 #~(read-everything-from-file
    #$(computed-file "unecessary-file-name"
       #~#$(local-file "blabla.sh"))))

when originally it was
(mixed-text-file
 "source \" "\n"
 (local-file "blabla.sh"))

3. Inconsistent with other home services.

I do not insist that one approach is superior to the other and there are
of course some pros and cons for both of them, but personally I find the
old one to be more user-friendly, simpler and cleaner.  Also, having the
new implementation stops me from upstreaming all other home services,
because almost all of them allows to use gexps inside configuration
field and resolves file-like object to the path in the store instead of
literal content.

Please, express arguments, opinions and rationales and let's decide:
Keep the new approach or return back to the original one.

-- 
Best regards,
Andrew Tropin