no one here to explain how the correct and clean way for a downgrade is from screenshot to windowsave?

Yes, but I have a life outside of helping on here. Whilst I do (generally) check these fora several times a day I may end up spending what time I have trying to help other people.

You could have looked at the Makefile to see what is involved in installing, backed up the files that would get overwritten (just incase you need to restore them if anything goes wrong) and gone ahead with the install. That's the great thing about Linux and the RPi, just about everything is there for anybody to look at. There have been numerous times when I've had a problem with a program, the manuals haven't helped and nor has searching online, so I've either tried winging it and see what happens or I've download the source code and figured out what is going on and what needs to be done to get it to do what I want. It may take longer than asking online or it may not, either way it sticks in my mind a lot better for having worked through it myself and I'm more likely to be able to work things out quicker in the future.

Anyway, rant over. Sorry, it's been a long afternoon in the shop and a long bus ride home on a hot, stuffy day (it started so well with a nice cooling shower but spoilt itself by the sun coming out).

Installing whichever branch should copy over the correct files for that branch.

The headers of the newly installed branch will overwrite any previous headers, the library will copy over usually as a separate library (I think I remembered to increment the revision numbers each time) so that any previously compiled program will still have the correct version to load. The linked name of the library will be overwritten so that it points to the newly installed one so that when you compile against it your program will be linked to whatever you installed last.

thank you very much for your help. Unfortunately I never use Makefiles, so I have no idea what make, sudo make install, make all, and make test really do in detail. I am used to simple IDEs like Arduino or Geany which handle that magic stuff for me. I only wanted to be sure not to get orphans or duplicates or wrong file version.

so I rolled back by checkout windowsave,
changed the 2 expressions -lGLESv2 -lEGL to -lbrcmGLESv2 -lbrcmEGL
in the 2 Makefiles,
but got some warnings with make, just to let you know for bug fixing, and also there are again some errors about Dot():
cd openvg
make

I am quite sure that Dot() once worked on Jessie (don't remember which version though), but which branch or version now has been proven to work for Dot() reliably on Stretch?
(It's above all for 1 dot = 1 pixel, not for larger spots/marks)

doesn't draw. That is the branch where the rough and smooth were the wrong way around when defining them so when you pass false for the smooth parameter it tries drawing the rough path but the rough path is empty (it drew the rectangle to the smooth path).

I really aught to correct that bug in that branch. It's a very simple fix if you want to do it now, not sure of the line number (I'm not at home and github doesn't show line numbers).

In libshapes.c near the end of the Init() function you'll see the following line

Done, branch windowsave has the paths fixed for dots. Also, smooth seems to be working again, albeit it's rendering as octagons rather than spheres (the updated client/dot.c shows it by scaling the dots up by 16x).

Thank you!
actually I made some alterations, e.g. I changed the 2 expressions -lGLESv2 -lEGL to -lbrcmGLESv2 -lbrcmEGL in the 2 Makefiles and after that made all those make things.
Nonetheless,I will try the
git pull --rebase
first of all.

Just FYI,
the make in openvg still had the wrong paths instead of -lbrcmGLESv2 -lbrcmEGL,
but in openvg\client\ this already was correct surprisingly!

Thank you very much for your efforts!

Oops, yes I updated the one in client because I needed to run the demos, but the demos don't link dynamically against the library, they link statically with its object files.

I'll update the main Makefile (probably sometime in the afternoon) otherwise it will link to the MESA libraries which will likely fail when you try to run your program (especially as the MESA EGL library won't contain OpenVG but the Broadcom version does, a horrible kludge it looks like they did to get the Android linker to accept it).