I just discovered the same problem in alpha.9503. For me, IPv6 is configured in its default (automatic) state on both sides of the connection […]
And you were using 127.0.0.1 and had no IPv4 connection setup between the two machines?
No, I'm sorry, the connection between the two machines is IPv4; I only mentioned my IPv6 config to indicate that it does not deviate from the default configuration. I should have given a more complete description of my setup:
TextMate and ssh config set exactly as the examples in the documentation. Local (TextMate machine) IPv4 address is DHCP-assigned (e.g. 10.0.1.100). Server's IPv4 address manually assigned (e.g. 10.0.1.8). No IPv6 addresses configured on anything other than each device having the default IPv6 settings (i.e. stock OS settings) on the loopback interface.
I don’t know why it was failing and it’s not failing for me, but using the IPv4 IP made it work, and that is why we changed the documentation. Since then, only you and Brian have reported issues (with ‘127.0.0.1’) and in both cases it sounds like the reason is lack of IPv4 (in Brian’s case it was disabled via an SSH setting).
I think in both cases it's lack of IPv6, not IPv4, unless I'm misinterpreting something. In Brian's case it was IPv6 that was disabled via the AddressFamily setting (from the man page: "valid arguments are ``any'', ``inet'' (use IPv4 only), or ``inet6'' (use IPv6 only).") Brian's setting "inet" would have forced connecting using only IPv4. Removing the directive presumably is equivalent to "any", so my assumption reading his description of the problem was that it ONLY worked for him when IPv6 was available. That's what lead me to try changing the address in the config--initially the setup described above worked, but after an update (I'm not sure which one), rmate started producing the same error Brian described. My guess is that the original IPv4 numeric address similarly forced the connection to IPv4, but switching to the hostname, which resolved to both v4 and v6 addresses allowed it to work (ultimately because it was communicating via IPv6).
That said, I did a little more troubleshooting. I did a packet capture of several communication tests (using telnet to try to reach TextMate on port 52698). I tested over the ssh connection forwarded back as well as directly from the local client (taking remote forwarding out of the picture), and each test involving the IPv4 address failed, while those involving the IPv6 address succeeded. Those using the hostname "localhost" succeeded only when it resolved to the IPv6 address; removing the IPv6 address from /etc/hosts caused it to stop working. For IPv4, the packet trace shows the initial connection packet, an acknowledgment, and a connection reset with no further communication. I also have a clean install of Mountain Lion in a virtual machine that I use for testing. I put TextMate on it and ran the same tests there--fresh OS and TextMate install, default configurations, same behavior, so it is repeatable.
It seems to me that TextMate is only listening on IPv6 now. But I'm not familiar with the inner workings of all that nor with the TextMate source code, so I'm only basing that on the observations I've shared here. If I can provide any additional troubleshooting information to you, let me know what you need--I can send you the packet trace logs or if you have any suggestions on what else to look for, I can try out some other things. It is working for me now, just not as described in the documentation, so I'm not suggesting it's completely broken. But I do think there's something wrong with IPv4 and if you want to get to the bottom of it, I'll be happy to help out.