If you are referring to the Wireshark "data length" column, that is a SUM of all IP fragments of one TCP segment.
The reason why this is done is that your OS is actually sending big TCP segments to the network card and the network card does the fragmentation to the (smaller) MTU, that's why you see that you're sending 2776 bytes long frames (the same can happen on the receiving side I think). If you'd sniff directly on the wire (a switch for example) you would see only 1518/1522 bytes frames.
This is called Large Segment Offload and is a function of a network card. It can be turned off and then the OS will have to send frames to the network card which are under the MTU limit.
1. What goes into setting the MSS?
In the question you referenced it stated this, the MSS is derived directly from MTU. A typical Ethernet MTU will 1500, but IP and TCP headers must also be taken into account - each of them are 20 bytes.
Note: Just an FYI, MTU can be different sizes - see Jumbo Frames for an example.
We end up with:
MSS = 1500 - 20 - 20
MSS = 1460 bytes of TCP data
I'd like to emphasize something you mentioned, you are 100% correct in stating that the MSS for the TCP connection is established during the 3 way handshake. Should either side of the connection want to adjust its MSS, the TCP connection would have to be torn down and re-established. Before going any further, we need to clarify that a "receive MSS", what you're thinking of is the TCP receive window. This is not the same as the MSS.
2. Do other factors go into the calculation of one side's MSS?
So remember, the TCP MSS is established during the TCP handshake along with all of the other session options. The vast majority of the time the agreed upon MSS will be the largest possible payload that can be sent in a TCP segment without fragmentation. The last part is key, this means if a client and server are trying to establish a TCP connection, and the client has a smaller MSS size set, the connection will choose the smaller of the two values to avoid said fragmentation.
As it should be noted, it is possible to manually set MSS if whoever is running the application/service doesn't care about fragmentation.
3. What factors does a Client or Server use when they state "I want you to send me TCP segments in maximum chunks of X bytes?" Is it solely based upon the MTU?
The bottom line is that TCP will try to squeeze as much data into each message as it can to maximize network efficiency. To be clear, a single un-fragmented TCP segment's payload (headers, data, options, etc.) CANNOT exceed than that of the MSS, if that single TCP segment is one message, or a piece of a fragmented one is irrelevant to TCP - that's what it's designed to handle.
It's not solely based on MTU of the end hosts, but as previously mentioned it is derived from it. Things like a lower "Path MTU" (see Path MTU Discovery (PMTUD)), can affect network performance.
Other factors can affect network performance as well, but not necessarily only MSS. You can check out things like TCP Tuning, if you'd like an idea of what else you might think about when designing an application or service around TCP.
Best Answer
Well technically fragmentation can happen in IPv6; This is the wikipedia article on it.
This Juniper page is a bit old but it shows that you can clamp an MSS for TCP over IPv6 on Junos the same as you would in IPv4 using the same command,
tcp mss. The same is shown in this article for Cisco IOS 15, using the traditional ip tcpadjust-msscommand.So you can configure MSS clamping if PMTUD isn't working as it should be in a part of your network, otherwise, you should be ensuring that you are aiding the smoothing running of PTMUD across your networking so that MSS clamping isn't required (I understand this isn't always under your control).
Update
Here is a link to a newer Junos article for Junos 10x rather than 9, I can't find one for 11 and I'm not in front of 11 right now, but I expect it will be the same.