I’ve read this post and it’s not difficult to implement: just copy that text.
But I don’t understand why I need to do this and more important, what to do then when “it will trigger the hook, which will call the script, and output something like this”?
In addition, what happens and where? Does something happen even if I make updates from Software Center, not using CLI?
There is a lot of information in this Arch article of which Manjaro is a derivative.
If that would not explain the why, please refer to the exact paragraph number that is unclear to you and we’ll update the guide.
P.S. A Tutorial article’s thread is for explaining how to do things, the Manjaro Wiki or the Arch documentation are there for the “Why?”
Right. I read that Arch article. Now I know why. At least in some level.
However, on Manjaro Wiki, I made search query “pacnew” and found a page System Maintenance.
I did try to learn, what I should know when doing “manual intervention” to these Pacnew and Pacsave files. I think that I didn’t understand enough.
This point doesn’t sound good to me: “Unfortunately, there is no perfect road map for how to deal with these files. If you keep the original config file, and the syntax has changed, the program may stop working or fail to use the existing config. If you remove the original file and use the new file without any changes, all your configuration settings can be overwritten. Sometimes, you need to combine pieces from the new and old files to make everything to work. In these situations it is better to integrate the files manually.”
I think I don’t have skills to do this.
Does this mean that there will be a day, when my Manjaro installation won’t work any more, or at least not well? If yes, approx. how long it will take?
You give yourself to little credit, finding out about the existence of .pacnew files before you have to fix a issue already gives you the advantage of being able to prepare and learn. Important changes are announced in #announcements:stable-updates threads when extra care is needed or manual intervention is needed in specific situations.
The last year I’ve had to merge things maybe 3 or 4 times iirc and those where mostly added options in a config file. Your system will probably break sometime in the future but with good care it could be the hardware the breaks first 
The best way to find out is to learn and do is my experience, you learn about the config files, the options, what is new and what some of the components under the hood are and do. And in such a way that probably hasn’t broken your system yet!
I’ve found the use of a visual diff tool immensely valuable, I use meld.
Install meld:
$ pamac install meld
check:
$ sudo DIFFPROG=meld pacdiff
I did try meld. Don’t know what to do with it.
Then I did try from Arch wiki this command “find /etc -regextype posix-extended -regex “.+.pac(new|save)” 2> /dev/null”
Result:
/etc/mkinitcpio.d/linux510.preset.pacsave
/etc/mkinitcpio.d/linux512.preset.pacsave
/etc/mkinitcpio.d/linux514.preset.pacsave
Don’t know what to do with them. Remove? Can there be more somewhere else? This is approx. 1 month old installation.
I have been trying different kernels, learning that older 5.4. seems to be only one, when my touch pad works. I know I removed those kernels.
Is this pacnew and pacsave issue related to Arch and derivatives only? Is there same kind issues with other distros, which has different package management?
The article explains it all if you read it.
.pacsave
If the user has modified one of the files specified in
backupthen that file will be renamed with a .pacsave extension and will remain in the filesystem after the rest of the package is removed.Note: Use of the
-noption withpacman -Rwill result in complete removal of all files in the specified package, therefore no .pacsave files will be created.
a .pacsave is kind of a backup of the configuration file, when you remove a package that used this configuration file. They are most likely always OK to delete, if you removed and don’t plan to use again the related package.
There is no issue there, this is how Arch based systems work, they do not overwrite your changes, they on purpose create a .pacnew file when a package receive a change in its default config file, so it is to the user to decide what to do with it. Some other distributions decide they take care of that for the user. I prefer to have to take care of changes personally instead of having my config file overwritten every time.
For what to do with the .pacnew, it is to you to have the judgment call. Often it is OK to simply overwrite the config, but NEVER do that blindly, you first need to make sure it is OK to do so because it can happen that a critical system config file receive an update, and it creates a .pacnew file then, but overwriting your config file with the .pacnew can result in a “destroyed” system, so first make sure what the config file is for. A couple examples:
pacman.conf.pacnew appears after an update, think about what the config file is for so “what is pacman?” and “do I need to keep my original config file?” or “can I overwrite the config without issue?”.
Pacman is the package manager, the program received new changes that have new settings, if you didn’t change anything yourself in the config, it is safe to assume that for this specific program you can overwrite the config if you didn’t have your own modified settings, or you can merge the config if you want to add the new settings and keep your old settings too.
The same would go for non critical applications, like a text editor, a video player, a PDF reader, programs that are not critical, that you didn’t specifically configure for your needs, or that you don’t use, usually you can overwrite the config file (but again, always check and read the difference between your original and the .pacnew config file, to see if it is only a few values that change, or the whole file, and make the judgment).
Now a shadow.pacnew file appears after an update. Same thing, “what is shadow?”, and “what is this config file for?” a quick look in a search engine would quickly prompt you to know that this file is the one storing your user accounts password and vital information for the system to work. With a little bit of common sense you would at least ask yourself “is it safe to replace the file holding my system accounts password and important information?”. Spoiler alert, for this specific config file, OF COURSE you do not overwrite it with the new .pacnew file, or else the system wouldn’t recognize any accounts and password, resulting in a broken system, not that easy to recover especially for non technical person. In this case, the .pacnew file is here because the default config file has changed in the package, but this is for newly installed systems that these changes would be required. In this case, simply delete the .pacnew file and keep your config file unmodified.
So there is not an easy answer for what to do with the .pacnew files, it is to you to try to understand the implication in replacing the config file with the .pacnew, or keeping your config file (or merging the few new changes).
With time in doing so you’ll be more confident and less scared of messing things up. It is a learning process, but with some investment it is not that hard, you just have to be careful and think about it.
In last resort, you can also search the forum, and if you can’t find information that helps, maybe open a support thread but I don’t think you should open one every time you have a .pacnew file in your system. Do your research, try to understand.
Also a good way to avoid messing the system, is to use TimeShift (and configure it so it doesn’t take any snapshot by itself, by default it would do automatic snapshots at different time, I do not recommend this behavior). Then every month before doing one of the big system updates, just create a snapshot from TimeShift interface (it is just a click and few minutes to wait for) so you know you could go back on this specific system state before the update, in case you mess something (or if the update fails). If something goes wrong, use TimeShift, tell it to restore the system state from one of the snapshots you created, it will restore the system, reboot, and you’re good to go.
Now how to use Meld? as explained sudo DIFFPROG=meld pacdiff will use Meld to compare the original config file and its .pacnew, each file being on one side to see the differences more easily. You can then manually write some changes, or click the arrows to directly send what is different to the other file (make sure of what you’re doing at this point don’t click-click-click without understanding). Again it is not easily explainable what to do, but usually the config files are readable, settings use words and you can also have comments/description that could help.
Long read but it is hard to compress explanation, as it is not really explainable 
As your original question to “Why” has been solved by the article, please open a new topic if you would have a specific problem and quote the exact article paragraph step where you’re stuck.
Therefore, I’ve marked this answer as the solution to your question as it is by far the best answer you’ll get.
P.S. In the future, please don’t forget to come back to your question after your issue has been solved and click the 3 dots below the answer to mark a solution like this below the answer that helped you most:
so that the next person that has the exact same problem you just had will benefit from your post as well as your question will now be in the “solved” status.