so I played around with vp9 enciding a bit more.
apoarently there is vp9 lossless mode, and additionally libvpx can support high bit depth if configured so.
Tested on my laptop and the lossless file is, as expected, 15 times larger but looks better. Thank you Andrew.
Will compiling with vp9 multibit affect any loading or rendering of vp8/vp9? I will try to check this and test it too.

not sure why this still not default - may be due to libvpx size or speed?

Good news. The directory containing the libvpx code is only 4 M larger and the bin/cin file is just a little bigger (about 150KB if I calculated it correctly) with the patch in. But I did not check the compile speed yet. File size differences are in:

96K ./vpx_scale/generic
144K ./vpx_scale

424K ./vp9/encoder/x86
4.0M ./vp9/encoder
420K ./vp9/decoder
68K ./vp9/common/x86
1.0M ./vp9/common
5.8M ./vp9

2.6M ./vpx_dsp/x86
7.0M ./vpx_dsp

There are these files that maybe can be gotten rid of in the compile if there are options for that if necessary later:

3.3M ./docs
240K ./examples
1004K ./third_party/googletest
448K ./tools

I think I created small local hack fir deleting all *. o files, just run this line from thirdparty dir after all components built successfully:

find . -type f -name '*.o' -delete

{from thirdparty/Makefile}

this way you will have a bit more space for building/linking cingg itself

More good news is that 1 test rendering the same file with the enable in and with the enable out came out exactly the same.

Now on to testing 0002-Remove-libavdevice ... by Andrew.

if this change does not break normal cingg input/output it may even balance out prev. change in terms of compilation soeed and size

I wonder how much slower vp9 profiles become if you choose 10/12 bit vp9?

And how quality of encode/decode compare with normal 8bit vp9.. but this is not urgent.

ps: you also hoped to push jp2.dfl file?