Note that pledge() is not a Linux system call, so it is unavailable. AIUI, it is not terribly far away conceptually from our sandbox model in that some things are default allowed but with restrictions (akin to our default template) and others things can be declared with ‘promises’ that are not dissimilar to what snap interfaces achieve.
The thing is, for a general purpose tmux you actually don’t want it confined since you want to be able to do anything, just like with a shell.
For a snap to ship a restricted tmux, the tmux code itself needs no special permissions, but it must use the libutempter library which requires the utempter setgid helper which is not shipped in base snaps so must be shipped by the snap, which isn’t allowed to ship setgid binaries (for many reasons, not least of which, the gid in the snap won’t be the same gid across all distributions). Furthermore, as a snap under strict confinement, there are a number of challenges related to snaps running other snaps or arbitrary commands (as mentioned above). Eg, it runs in its own mount namespace, under its own seccomp profile (and syscall filters can only get more strict), runs in snap-specific cgroups and under its own snap-specific apparmor profile (which is somewhat easier to deal with since apparmor supports exec transitions). I have explored what a special tmux (or screen) interface might look like on several occasions but it is quite problematic without tmux understanding external sandboxing concepts (some of which might need to be invented to be performant) or exposing arcane sandboxing options to users.
IMO (and I’ve mentioned this https://forum.snapcraft.io/t/attempting-to-snap-screen/4917), Ubuntu Core should ship tmux and/or screen in the image so shell users have access to it. Classic distro users either use distro packaging or a classic snap. It would not be impossible to introduce an interface that when plugged would make the snap behave like a classic snap, but this obviously doesn’t address the request here for some confinement and completely bypasses the current design of ‘classic snaps not allowed on Ubuntu Core’.
That is the official answer. As a user/tinkerer, if you have a UC device, it should be possible to unpack the tmux and libutempter0 debs on a UC device (eg, Ubuntu 18.04 LTS debs on a UC18 device) and make adjustments to the tmux invocation so it works. Then one could write an apparmor profile in /etc/apparmor.d for tmux to restrict it to site requirements (and if UC shipped it by default, the admin could write an apparmor profile for it). This is clearly unsupported, outside of spec and inelegant.