Of course. I'm really not sure what changed. If you have a specific demo file that should work, send it and I can try playing it back.

Seemingly so, the only things I would have changed was I tried killing steam after starting tf2 to see if demos would play then (they didn't, it crashed), and I also tried replacing steam_api.dll and steamnetworkingsockets.dll in the old version with the versions from the latest release of tf2.

I reverted everything I did, yet somehow demos play back fine now without crashing tf2. The demos I tested were the mastercomfig benchmark_test.dem and benchmark1.dem from the tftv benchmarks thread, as I knew both of those are supposed to be able to play in this version of tf2.

You're right, same for me, yet another crash when trying to actually start playing a demo. Probably also Steam related, no clue how to get around it though.

Edit: demos started to play back fine for me now, I don't know what changed

It seems to work still, but as before you continue to need Steam in offline mode. Steam in online mode -> crashes.
Steam not running at all -> crashes.

Mac executable has been presently removed, it's likely done.

"DefaultFixedOutline" font in resource/sourcescheme.res

dxlevel 81 works fine but I guess it looks like the launch option is messed up, you can change dxlevel by navigating to HKCU\Software\Valve\Source\tf\Settings in regedit and simply setting DXLevel_V1 to your preference.

the dxvk garbage only works on dxlevel 90 / 95 / 100, black screen on 80 or 81. honestly wouldn't recommend using dxvk on windows anyways.

You should be able to download the old version (manifest ids can be found here) using depotdownloader / steamcmd / steam console.

I'm sure you've already tried restarting steam (fully exit and relaunch, or reboot your pc) but in case not, that's certainly something worth trying

Well it's hard to say anything too definitive without knowing more about your setup but usually to display the output of an egpu on the internal screen of a laptop you have to copy the framebuffer back off of the egpu over whatever interface it's connected via (ExpressCard in your case, which isn't really that fast, basically a single PCIe 2.0 lane at best) and onto the gpu attached to the internal display so it can be displayed there. There's overhead in doing that, in multiple stages of the process, and also when using a slow interface like ExpressCard it could cut significantly into the PCIe bandwidth that you would otherwise be using for everything else the gpu has to do, lowering performance in your game.

It's hard to imagine that the limit for how fast you could copy the framebuffer would be as low as 60-ish fps for normal resolutions on any somewhat recent (past decade or so) hardware, so maybe it's worth going through the display settings for the gpu to which the laptop screen is connected and making sure there's no vsync forced in there or something, but ExpressCard bandwidth is very low so it's possible you're just really running into that limit.

The best test you could do would be to just try a monitor plugged directly into the egpu if at all possible and to check whether the issue is still occuring or whether it's remedied by doing that. You could also try a very small resolution like 640x480 with your current setup and see if that has any effect, as it would require much less bandwidth to copy than a larger resolution.

Are you using a monitor plugged into the gpu, or the internal screen

probably would break linux bugs idk though https://jump.tf/forum/index.php?topic=3426.0

Seems to crash due to some divide by zero when you have the width narrower than 640, I don't know how to fix it but I was able to reproduce the problem if that helps. You can put the height lower than 480 fine, so maybe that works for you (eg. 640x360 or something)

It's definitely a hud-related / hud-adjacent problem, for example if you do cl_drawhud 0 it doesn't crash. It also seems like you can get around the crashes by launching in a normal resolution, joining a map first, and then changing to your small resolution with mat_setvideomode or something, seemingly no crashes after that even when loading a new map or doing hud_reloadscheme. More of a workaround than a solution though. I wasn't able to narrow down what specific part of the hud (if any) is to blame during the short while I spent looking at it.

I don't know if this will necessarily be the case, 64-bit might help with the occasional out of memory crashes that people experience in certain rare circumstances, and maybe fix things like this, but gmod for example has a 64-bit version and it performs about the same as the 32-bit one. I guess it's good future-proofing if microsoft ever decides to drop the 32-bit libraries from windows.

As for vulkan, valve has already released a vulkan shaderapi for games like csgo and portal 2 and at least on windows it seems to perform pretty consistently worse than the directx one across the board, but who knows, maybe tf2 will be different for some reason. For linux it's definitely a welcome addition.