I'm afraid there are no choice except using two versions of gcc in a same time, just because it's easy way. I'm not expert too, but read that gcc developers completely rewrites its code, see a lot of bad feedback about gcc5, see files likes "gcc5.patch" for latest versions of almost all packages in dev-repos of some distros.
> some of the packages described in the LFS/BLFS book require patching, also described in the book.
> will not be able to use the proposed patches
Guess we can use every patch except "gcc5.patch". Some patches may be not described in the book, you can see it in git of every "fat" distro.
> Will it be possible to “save” all the packages after the upgrade Glibc?
Now we have not only humble human resources, but unsufficient machine resources too. In theory: we can disable pushing to mirror, upgrade, recookall, downgrade in case of bad result. Or build toolchain in chroot, copy wok to chroot, recook all. Now we know number of packages broken by update. But look on our build host: no enough disk space, "intel atom" instead of CPU, so it's just theory.
> What is your opinion about the Glibc version 2.22?
It needs patch for 32-bit build. And it's our main, in fact - only one SliTaz arch. If it's impossible to build glibc without patch, how it will work on it? Anyway let newer glib be highest priopity task. I'll try to build it, and test how it works with old gcc463.
> 2.15
There was some critical bug exactly in 2.15.(Or 2.13? read this about two years ago, not here, lazy to find it again.)
> I remember to update Glib is completely painless, we can move on to a newer or older non-dev-version of Glib. To which one?
2.44.1 should not broke something if its devs don't lies in changelogs.
> We can stick with the current used Linux Kernel 3.2
Agreed, my hardware are old too, so works fine with 3.2
In general: just decide to risk or not to risk...Why are you not using "undigest"?
I can't feel more skills than you, but will try to fix broken "if something".