Yes, so many packages depend on pango, we'd better to update it in 'core-updates'.

Maxime Devos <maximedevos@telenet.be> writes:

> [[PGP Signed Part:Undecided]]
> Zhu Zihao schreef op vr 11-03-2022 om 23:15 [+0800]:
>> +(define-public pango-next
>> +  (package
>> +    (inherit pango)
>> +    (name "pango")
>> +    (version "1.50.4")
>
> Due to pkg-config requiring propagation (*), this can probably
> unfortunately often cause profile collisions.
>
> Greetings,
> Maxime
>
> (*) Could be avoided by symlinking pkg-config files into the pkg-config
> directories of their dependent libraries, as suggested by lilyp.
>
> [[End of PGP Signed Part]]

Not only for pkg-config files, but also for headers.

For example, the header of gtk4 may have following lines

#include <pango.h>

> What if a program uses both 'pango' and gtk?  Then IIUC, it would
> simultanuously use pango and pango-next in the same process, which can
> easily cause problems (see e.g. the bug report about segfaults
> involving multiple libcairos).

If package A propagates C@1.0 and package B propagates C@2.0. Guix will
raise an error. However, it doesn't care about something like

guix shell gtk pango@1.48

IDK which pango will win the game.

I've asked in https://debbugs.gnu.org/cgi/bugreport.cgi?bug=44327 and
suggest to introduce priority mechanism like Nix. But Ludovic Courtès
doesn't accept my suggestion.

-- 
Retrieve my PGP public key:

  gpg --recv-keys D47A9C8B2AE3905B563D9135BE42B352A9F6821F

Zihao