I haven't yet been able to test this in a non-production environment, but at the very least trying to include 1.5.0 in dev as a gradle dependency causes failure to boot.
this worked fine in 1.4.5

build.gradle line:
runtimeOnly fg.deobf("libs:block_renderer-1.16.4-forge-fabric:1.5.0")

Error:
[15:31:13] [modloading-worker-29/ERROR] [ne.mi.fm.ja.FMLModContainer/LOADING]: Failed to create mod instance. ModID: block_renderer, class com.unascribed.blockrenderer.forge.BlockRendererMod java.lang.ExceptionInInitializerError: null at com.unascribed.blockrenderer.forge.BlockRenderer.<init>(BlockRenderer.java:27) ~[block_renderer:1.16.4-1.5.0] {re:classloading} at net.minecraftforge.fml.DistExecutor.safeRunWhenOn(DistExecutor.java:137) ~[forge:?] {re:classloading} at com.unascribed.blockrenderer.forge.BlockRendererMod.<init>(BlockRendererMod.java:21) ~[block_renderer:1.16.4-1.5.0] {re:classloading} at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) ~[?:1.8.0_202] {} at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) ~[?:1.8.0_202] {} at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) ~[?:1.8.0_202] {} at java.lang.reflect.Constructor.newInstance(Constructor.java:423) ~[?:1.8.0_202] {} at java.lang.Class.newInstance(Class.java:442) ~[?:1.8.0_202] {} at net.minecraftforge.fml.javafmlmod.FMLModContainer.constructMod(FMLModContainer.java:81) ~[forge:36.0] {re:classloading} at net.minecraftforge.fml.ModContainer.lambda$buildTransitionHandler$4(ModContainer.java:120) ~[forge:?] {re:classloading} at java.util.concurrent.CompletableFuture$AsyncRun.run$$$capture(CompletableFuture.java:1626) [?:1.8.0_202] {} at java.util.concurrent.CompletableFuture$AsyncRun.run(CompletableFuture.java) [?:1.8.0_202] {} at java.util.concurrent.CompletableFuture$AsyncRun.exec(CompletableFuture.java:1618) [?:1.8.0_202] {} at java.util.concurrent.ForkJoinTask.doExec$$$capture(ForkJoinTask.java:289) [?:1.8.0_202] {} at java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java) [?:1.8.0_202] {} at java.util.concurrent.ForkJoinPool$WorkQueue.runTask(ForkJoinPool.java:1056) [?:1.8.0_202] {} at java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1692) [?:1.8.0_202] {} at java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:157) [?:1.8.0_202] {} Caused by: java.lang.NullPointerException at com.unascribed.blockrenderer.forge.client.varia.rendering.GL.<init>(GL.java:19) ~[block_renderer:1.16.4-1.5.0] {re:classloading} at com.unascribed.blockrenderer.forge.client.varia.rendering.GL.<clinit>(GL.java:16) ~[block_renderer:1.16.4-1.5.0] {re:classloading} ... 18 more

I believe this is caused by the GL class constructor attempting to use the Minecraft instance. Minecraft does not exist in datagen.
Any way we can just assign null to window if in datagen instead of client.getMainWindow?
the mod isn't needed to be operational for datagen anyway, it just saves having to change build.gradle when going between datagen and client debugging

Relevant line:
public GL() { this.window = this.client.getMainWindow(); }

Done a fairly quick fix.

The codebase needs (hopefully) a fairly simple redesign for laziness which would of solved this also. It shouldn’t really care whether the Minecraft instance is present until something needs it, which will stop these kind of bugs.

Will add running (or at least not crashing) in Datagen as a step to my checklist.