Breaking trough NAT without port forwarding - sure. The only reason why the protocol might not work with NAT with port forwarding is if it for some reason does not trust the header of the packet and adds a copy of the IP address in the data section (like ftp does).
That's not the only reason. IPsec, for instance, has to be wrapped inside UDP (called IPsec NAT-T) to break through NATs since IPsec was designed to be run directly on top of IP, where there is no concept of ports to forward! Any attempt to go beyond TCP and UDP runs horribly afoul of NATs.
So, I can make a packet destined to 1::2 port 80 (hmm, with IPv4 I can write 18.104.22.168:80, is some other symbol used for marking the port number? 1::2:3:4:80 could be confusing?) actually go to 1::3 port 80?
(To put a literal IPv6 address in a URL you write http://[2001:db8::1]:80/. I suspect other places expecting a colon-separated port number will use a similar scheme.)
Great - it means I can still publish only one IP and do the port mappings, which makes this "almost" NAT.
So, the only thing that cannot be done is rewriting the source IP field on outgoing connections (not packets, since for port forwarding to work it has to work both ways)?
Yes, not unless you use a proxy. Simple inbound port forwarding doesn't need to be implemented as some fancy stack-level kernel feature like NAT; you just need a process listening on a port that, upon accepting, makes a connection to another IP and port and copies the data in both directions. The classic cheesy way to implement this is to throw a line in inetd.conf that calls "nc ip port", though for things like HTTP an application-specific reverse proxy will work a lot better and possibly take some of the load off of your web server(s) if it caches.
It's likely a fair amount of NAT-like behavior will be written for IPv6 to support implementing transparent proxies, which do have to happen at the stack level. I just want the amount of NATted traffic on the Internet at large to be on the opposite end of the bell curve than it is now, since with IPv6 it will be unnecessary to "share an Internet connection" in the same way as IPv4.