The unexpected permissions and date of /home/share/wallpapers/ are because the command is still running.
Imagine tar is used by an ordinary user to extract a directory (owned by the user) with r-xr-xr-x permissions and some files within. If tar applied these permissions before extracting the files, it couldn't proceed with the files. To deal with this the tool grants itself write access first (rwxr-xr-x), restores the files, only then it changes the permissions to exactly what they should be.
tar extracting as root does it somewhat differently. It creates directories initially belonging to root:root without any access rights for group or other. Only after it processes all the files within, it sets ownership and permissions as they should be. This means temporarily even the ownership may not match. In your case the original directory is owned by root:root, so incidentally the ownership matches. Still you're observing the temporary user-only permissions.
Similarly, restoring timestamps too early makes no sense. Changes within the directory would affect them.
In any case the point is tar needs to delay restoring some metadata until it "thinks" it's done with the directory.
How can tar know this? Well, it cannot know for sure. Your extracting tar reads from a non-seekable pipe and it absolutely cannot know what paths it will get in the future. Even while reading from a seekable file tar would read it sequentially.
What happens is the tool assumes that after encountering share/wallpapers/ all the directory content immediately follows. In other words: after share/wallpapers/ there are zero or more files with paths starting with share/wallpapers/. Then a path not starting with share/wallpapers/ indicates we're done with wallpapers and the metadata of the directory can be finally restored. This approach works fine with archives created by a single tar processing a single starting point (like in your case), because the creating tar does process files in the expected order.
Archives created by more than one tar (e.g. think about --append) or when multiple files were specified in arbitrary order may contain members in unusual order. In this case the following option is useful while extracting:
--delay-directory-restore
Delay setting modification times and permissions of extracted directories until the end of extraction. Use this option when extracting from an archive which has unusual member ordering.
So it delays restoring metadata even more.
If your extracting tar used this option, you would observe unexpected permissions for /home/share/xindy/ and /home/share/wallpapers/ at the same time. You didn't use the option and apparently the observation was made after the extracting tar assumed it's done with xindy, therefore for this directory you observed the right permissions. At the time of the observation tar was not yet done with wallpapers though.
Wait until the command finishes. All the permissions should then be right.
