Double buffering screen

I think so.
According to Mapping c128, $0A2C is the location for VIC graphic/char pointers (eg. D018)
Normally this value is $14, causing screen to be at $0400.
If you update this value, the VIC will show another location (I expect you would move the $400 bytes to $B00, the ROM has to be able to see this)
This will change the 40 screen but not the 80 screen of course. Furthermore this will not cause the screen editor to access another spot. So you can keep printing to screen without this being visible.
Except... for the color. You will need to ALSO move to the 2nd color screen in the VIC.
For this you need to update the $D9 (shadow of CPU $1, where you can set the VIC color bank)

If you do not want to resort to POKEing, but instead want to 'print' to the other screen we would need to move the 'screen editor' area somewhere else. This is where it gets tricky, I think the ROM routines have e.g. 'row' tables (to not have to calculate the screen pos, given a row, but look it up) and these are adjusted with the 'screen base' at $0A3b (for 40 columns, default 04. if you set this to $0B the screen editor presumably will apply a chr$(147) to the area $0b00-$1000)
This also allows you to move the 80 column base. In the case of VDC you have no shadow and you can 'simply' update the screen ptr (and color ptr) in the VDC registers $0c, $0d ('Display Start H, L') and likewise $14 $15 attribute start H,L)

If you pull this all off, (quite some work), it would (in the end) be advisable to try and synchronize your screen-updating with the vertical blank (using a WAIT basic statement on the correct address).

There are examples of this technique, where people create a 2nd 80column screen and provide some code to switch.
Note that the system will not 'remember' where it was on either screen so you would do well to use absolute addressing and repeat the attribute setting (using CHAR is faster, I don't know if char also uses the editor ROM routines)