As @sp614x mentioned in sp614x/optifine#2419:

not all shader packs have separate shaders per dimension so with them there would be no shader switch when changing dimensions and the performance should be ok.

Could you please add a "use-at-own-risk" option to enable see-through portals even when shader enabled?

Worth a shot, isn't it? （<ゝω・）☆

No shadows support for an experimental feature seems to be OK, at least for me. As for those "ghost entities", I'm aware of the problem as @qouteall mentioned here. I know little about rendering so I apologize if my question appears ignorance, but since you can access the shader's framebuffer, why can't you render with optifine's shader first and modify the framebuffer later? I mean, render most of the in-portal scene with fancy shader while render those incorrect portions with your culling shader, and composite them with, say, magic?

It's not actually that simple. I know there to be at least one other blocker for see-through portals with shaders:

• BP currently uses GL shaders itself to render the portal surfaces (not the texture, the actual see-through surface), so OF's shaders would have to be re-activated after BP's are done (or BP would have to use a different way of drawing the portals)
• Looking at ImmersivePortals' OF code, it looks like shaders don't support glClipPlane which is essential for the portal effect as it removes anything on the not-visible side of the portal (an example of that not fully working: #204, now imagine the same with blocks not working either).
• BP rather aggressively culls any chunks not visible through the portal, so those probably won't cast any shadows either

BP doesn't use the culling shader method (IP does). BP just uses good old glClipPlanes which should be more compatible with other mods because one can configure six different clip planes (and BP only needs two, one for the portal, one for entities standing half-way inside a portal) whereas only really one mod can use shaders at one time (it's not by default compatible with shaders though, at least this comment suggests that and iirc you need to do some extra handling in the shader to use it). The only sane way I can see to make it compatible with shaders is to do something similar as to what IP does: Modifying the shader code while it is being loaded (except maybe at a different point because I still want to use glClipPlane).

render those incorrect portions

That's not what the culling shader / glClipPlanes does though, the point of those is to determine which portions are the incorrect ones and then skip (or rather clip) those. I guess we could manually check each chunk/entity/whateverelse for whether it intersects with the portal and then don't use OF's shaders for those but that gets quite complicated to implement (and kinda ugly to look at since we'll be skipping the whole chunk, not just clipping a single triangle) to the point where the above option is probably easier to do.

Anyhow, I've marked this as a suggestion but don't expect it to happen anytime soon (what doesn't help is that OF still doesn't provide any source code for its changes, so I'm not particularly thrilled to work with it in general).

another approach might be to approach this the other way. rather than try and make BP with with shaders you could possibly code a shader pack (or module FOR one) to get it to work? idk if thats how it works but in general looking at a problem from the other way can lead to new insights so perhaps this is the way to go?

I would suggest a halfway solution that would probably not be too hard to implement: rendering "the other side" without shaders. Not only it would be already better than nothing, but I think it would even add some charm to it: you can see through the portal, but things there look kinda different... :)

Would this be possible with Optifine? Well, I've found this: sp614x/optifine#2959
I'm not sure if it's relevant, but maybe it helps?