There are two port forwarding modes allowed with slirp4netns. One uses slirp4netns itself: data is passed across a tap device, libslirp translates the destination address and preserves the source address.
The second one uses rootlesskitport (while slirp4netns still takes care of outbound connections): it opens sockets directly in the detached network namespace and passes data between sockets without going through the tap device. It's faster, because you avoid 1. the tap device 2. Layer-4/Layer-2 translations. But those sockets are local to the namespace, so destination and source address become loopback addresses. That might be unexpected in some cases, see also https://nvd.nist.gov/vuln/detail/CVE-2021-20199.
pasta implements both modes (it's the "tap bypass" in https://passt.top/passt/about/#pasta-pack-a-subtle-tap-abstr...), and selects the appropriate one based on the original source address, so that you don't need to choose one. Local connections skip the tap device, non-local ones go through it (you can have non-loopback source addresses only for traffic coming through a a non-loopback interface).
See podman-network-create(1), I think the description of the --driver option should clarify this. You can use macvlan there, but in rootless operation you don't have access to the network interface of the hosts -- unless you set that up networking separately beforehand (as root), that is.
So yes, it supports rootless, but by (kernel) design, there's no magic way to bridge (no pun intended) that gap (even with macvlan).
I have specifically not added that out of respect for what Slirp represented to dialup shell users in the late 1990s and for what it did for the ecosystem in the past 15 years. I used it for more than a decade myself, and if you consider that it's now used for containers and virtual machines, given the original purpose, it's really an impressive piece of software. Feature comparisons can be risky at times.
On top of that, you usually want to isolate the container workload with an observable network abstraction instead of granting it full (albeit non-root) access to host network facilities (including sockets).
The second one uses rootlesskitport (while slirp4netns still takes care of outbound connections): it opens sockets directly in the detached network namespace and passes data between sockets without going through the tap device. It's faster, because you avoid 1. the tap device 2. Layer-4/Layer-2 translations. But those sockets are local to the namespace, so destination and source address become loopback addresses. That might be unexpected in some cases, see also https://nvd.nist.gov/vuln/detail/CVE-2021-20199.
pasta implements both modes (it's the "tap bypass" in https://passt.top/passt/about/#pasta-pack-a-subtle-tap-abstr...), and selects the appropriate one based on the original source address, so that you don't need to choose one. Local connections skip the tap device, non-local ones go through it (you can have non-loopback source addresses only for traffic coming through a a non-loopback interface).