Portal rendering [1] was actually a well-known hidden-surface removal method long before the game Portal, right there with Quake-style BSP trees. It's actually somewhat surprising that it took so long for someone to turn them into an actual game mechanic rather than just an implementation detail, though I do believe some games used them to create non-Euclidean topologies…
The way Portal works was to render the world from two different camera angles, one at the portal exit, and the player view, and then combine them with a stencil buffer. This allows for recursion if desired. It also allows for moving portal entrance/exits without performance degradation.
The way Build mirrors work is to copy the level geometry across the mirror plane. Recursion or moving the mirror would not be possible.
No, not really. The engine needed a lot of help from the map designer to make mirrors work at all, and those weren't even traversable without cheat codes, nor were they more than the flex foone describes them as - that's the reason you see one early on in the first level, and very rarely thereafter.
Arbitrarily placed, see-through, traversable, Portal-style portals probably would not have been beyond the skill of the engine implementers. But to make them work smoothly, along with everything else in the game, under the constraints of the hardware on which the game had to run? I find it hard to imagine anyone being able to pull that off, tbh.
As a 3D engine programmer from the era, I feel like portals could have been pulled off with relative ease. It's more a matter of wanting to do it. Someone today could demake Portal to a nineties era engine I'm sure.
Dark Forces (a Star Wars 2.5D FPS from the 90's) used portal rendering. This let you create impossible geometry, like making a doorway that appeared to be for a small room on the outside was actually a portal to a larger room on the inside (think the Tardis from Doctor Who).
I think the trick would be to realize that the texture on the mirror or portal represents the same screen height and position, just at the virtual screen location of the mirror/portal player behind it. So you render the screen space column as the flipped/mirror column but move the camera, avoiding overdraw, and use the fact that back faces on the wall/mirror texture are invisible from out-of-bounds. Something like that.
If you can lie to the engine and say that the flipped/portal camera is still inside the sector that the player is in (even if that's clearly wrong by the camera coords) then maybe your engine culls walls/floors/sprites not visible and you don't need to reserve an empty void for the mirror/portal camera to render from, so that level geometry can occupy the back side and make the illusion convincing.
To your point, I think that you could generate the duplicate geometry pretty easily but the issue would be making sure no overlapping sectors were visible at the same time, as that would cause glitches in the Build engine.
You might be able to subdivide the build engine's sectors into visleaves (borrowing terminology from Source) and clip all sectors in the mirror-verse according to the aperture + view-frustrum. To work correctly you'd need to do this every frame, probably an unthinkably huge task for the hardware at the time.
I remember the Descent map where there was a very large room you could fly out of and into a corridor. The corridor looped around and went through the center of the big room, but the room in question didn't have a big column through the middle of it. So you were sort of in the room but also not when flying through the corridor. I seem to recall that while other players couldn't see or collide with you, they could shoot you if they somehow figured out where you were.
