(one of AwesomeWM maintainer here)
This is a rather common issue for all OS, but even more annoying for tilling WMs since it messes up with the layouts.
The good news is that a lot have been made to fix this in AwesomeWM git-master and more is coming.
What's there:
* If you set the `-- awesome_mode: api-level=5:screen=off` modeline at the top of `rc.lua`, all screens will be virtual rather than tied to a physical screen. In practice this means you can block and act upon physical screen removal. Previously, once the screen was gone, it was gone. Now you can either have full control or have the default handler
* Screen swap: You can swap your primary screen back yo your laptop screen when disconnecting. So at least you don't lose everything.
* Screen splitting: If you have a extra wide or double width monitor, you can split it in multiple virtual screens. This helps since it allows you to have the "main" virtual screen the same aspect ratio as the laptop screen. It means nothing moves when you switch back to the laptop mode.
* Full signals and handlers for everything: By default it's still not perfect, but at least there is sane ways to plug your own logic everywhere in the screen removal and addition process.
* Better mixed DPI: It is now easier to ignore the DPI X11 think it has and override it before the screen gets created. This way, you can ensure your laptop and main screen use something sane when in mirror/presentation mode.
* Tags (workspaces) have a `request::screen` to "save" them when a screen is gone. So you can send them to a screen that still exists without losing the layout.
What's coming:
* There will be rules to apply can screen changes (https://elv13.github.io/declarative_rules/ruled.screen.html). This will allow a declarative syntax to define the behavior on screen change.
* The ability to have "sets of workspaces" you can share across screens (XMonad style). This is an interesting solution to the problem. Since the same "state" can be shared by more than 1 screen, then adding and removing a screen doesn't destroy the state. However this is really complex to bolt on the current design and I have been trying for like 2 years to make it perfect and backward compatible.