I know this might be a weird and out of the way feature request, but I recently made a similar request on optifine's github, and realized it probably wouldn't really be worked on / accepted.

So I thought I would come here instead.

I had an idea for optifine to release a "Non Performance" version in which optifine would run without any of the performance modifications.
The main reason for this is to still be able to use features like CEM and CIT but also allow for compatibility with sodium, lithium and iris, or any other mod that might not be compatible.

I was hoping maybe optifabric could do it directly by disabling certain aspects of optifine and allow other mods that interfeer to work properly.

I know this is alot to ask, but I was hoping it could be considered.

Optifabric is a glue-layer between the optifine and the fabric modding system; see How it works on README.
And the difference between "optifine replacement class" and "original Minecraft class" causes mod incompatibility issues.

So your goal can't achieve without a deep knowledge of optifine internal and choosing applicable patches one by one for every optifine release; I believe that it's not a goal of optifabric.

Topia is correct, OptiFabric just applies whatever changes OptiFine causes without any information about what the changes are.

For example, OptiFine H8_pre7 for 1.19 changes 373 classes. A minority of those are just inner classes being produced as a result of their outer class being recompiled. So applying those either way won't make a difference. The rest will have some degree of change from (the equivalent of) one line to vast changes in multiple places. These changes could be something for performance, for shaders or some other resource pack effect, just as a result of recompiling decompiled code, or even an accidental change (perhaps from misporting something or a typo).
You could go through them all and categorise the nature of the change, then you could start on something like your idea where you can pick which ones you want. Of course, this presumes that the changes neatly fit into just the one category, support for shaders for example is often nestled alongside performance tweaks as a result of said tweaks moving where logic is. We'll say for sake of argument that they do; in that case you have the categorisation for the one version. When the next version comes out, you'll have to go through it's changes and categorise those. Some automatic comparison to the previous version could speed the process up for sure, but if you're jumping Minecraft versions that might not be too much help (as the code being changed will itself have changed as part of the jumping versions). Hopefully you can see that this process is not the most sustainable in terms of time.

If someone wanted to do it OptiFabric could certainly support their categorisation, I admit it was something discussed for the 1.15 snapshots (the idea being to unofficially update OptiFine and just cut out the bits which didn't work) right up until the very early ones changed quite a lot more than expected around rendering. At the end of the day though, your (or anyone else's) time is better spent playing the game than disassembling OptiFine patch by patch, be it with OptiFine's monolithic nature or Sodium and friend's much more configurable one.

Ah ok well thanks for the detailed response, thanks again for making this project in the first place! Thanks!