There is a map decompiler that converts BSPs into maps for HL1 that I considered using but I determined it was entirely too much work to get files that would be different than the source, since the BSP compilation process can add/remove vertices and wouldn't match up 1:1 with the original intent. + the experience with Hammer Source on linux and it just didn't seem worth it to me.

I ended up watching some tutorials on making HL maps which filled the gap instead - watching someone use a trigger_once or a func_breakable and seeing the parameters gave me a lot of ideas for how one could code an implementation of those using Bevy+bevy_trenchbroom+bevy_rapier3d as a learning exercise.

I was able to get triggers working pretty easily (using the new relationship structure for linking Entities and then pushing events that can be observed by any entity that responds to triggers and can run custom code) but I had to override bevy_trenchbroom's built-in DynamicLight classes in order to make them able to be toggleable (ie. turn light off on a trigger, etc.), so now my game config has a light_point2, light_spot2, and light_directional2 which stinks but I couldn't find a way around that. Of course, I'm not compiling to BSP which likely would have made this a lot harder as there's some hardcoded weirdness inside BSP files apparently.

Getting doors working was surprisingly difficult as the complexity is high, and I don't quite have it yet, but in general it turns out that according to https://twhl.info/wiki/page/func_door the movement uses the bounding box of the func_door entity for calculating how much to move the door etc. Doing that in Bevy was a bit complicated, as there are two ways I could hook into spawning (bevy_trenchbroom has spawn_hooks, and there's component hooks native to Bevy), and neither of them had access to both the Transform and the Aabb component by the time they ran, so I ended up adding a FixedUpdate system that would just do the calculations once everything was fully spawned and the spawn hooks got simplified:

fn setup_func_door(
    mut q_doors: Query<
        (
            Entity,
            &FuncDoor,
            &mut Transform,
            &Children,
            Has<TargetedBy>,
        ),
        Without<MovingBrush>,
    >,
    mut q_brushes: Query<(&Aabb)>,
    tb_server: Res<TrenchBroomServer>,
    mut commands: Commands,
) {
        // ...
        // Calculate the full bounding box of all brushes
        let (mut min, mut max) = (Vec3A::INFINITY, Vec3A::NEG_INFINITY);
        for e_child in children {
            if let Ok(aabb) = q_brushes.get(*e_child) {
                min = aabb.min().min(min);
                max = aabb.max().max(max);
            };
        }
        // ...
}

There's also a lot of complexity in functionality for func_door that surprised me! A door can open when you bump into it, or it can have a flag to make it InteractOnly, or if it has a targetname it won't do either of those and will instead wait for a trigger to trigger it. It's quite a diverse set of code paths for one thing and its been really fascinating to try and get it working, but I'm not there yet.