morgon wrote (the quotations may be slightly adjusted to add my emphasis or correct typos or produce clear formatting):

And are there any tools for bringing back Config.pm to properly reflect a changed system?

I cannot say there are not. I can say that there are no well known tools for doing that, and historically speaking it hasn't been considered a problem (such a tool would have been dismissed as “a solution seeking a problem”). This is no longer true - that's why I write historically. These days, a larger percentage of Perl users are working with a perl installed and managed by a package management system provided by a vendor (probably a GNU/Linux distro team).

My questions would be: Is manually updating Config.pm an acceptable risk or do I run the danger of some problems further down the road?

See the above. The first category of danger is precisely that implied by package management tools updating your perl installation. To my knowledge no such tool is designed to examine Perl's Config.pm for local changes, and therefor to forbear to silently overwrite it.

recently I had some troubles Installing Glib on Debian and after some digging the root-cause of my problems seemed to be a Config.pm that did not properly reflect the system anymore.

I have no idea how Config.pm and the system-state diverged (I assume the system was updated but not the perl) but I have manually updated Config.pm and everything works fine so far.

There are a lot of implications that led to confusion for me in what you've written. In the top posting you stated:

I am having troubles installing Glib for a self-compiled perl on a Debian-system.

In the referenced followup message you have stated that:

As far as perl is concerned the difference between the two machines is that one is 5.14.1 compiled from the source-tarball and the other is 5.16.2 installed via perlbrew.

From this description it is certain / obvious that neither perl is a vendor perl (provided by Debian). In this case, the apparent expectation that the perl Config.pm would “be kept in sync with the system” seems odd. It can only do so if perl is re-built and re-installed! How could it be otherwise? This is what building Perl is. It must be Configured for the system that it is running on.

If the problem system was the one with the perlbrew-created installation, then perlbrew is what you have to look at for defects / issues. If not, then your error must arise from incorrect self-administration (you did not build perl correctly / did not update the build-install after system changes).

It turned out that the "libpth"-entry in Config.pm contained "/usr/lib64" (a directory that does not exist on the system), but not "/usr/lib/x86_64-linux-gnu" (this entry controls which directories ExtUtils::Liblist searches).

Overall this group of postings makes a strong case for most Perl users to rely on vendor-provided package management teams and the work they do (especially at Debian). It makes a case for relying on them (and appreciating them), and using what they provide instead of cooking up your own Perl installation.