Yea, I had tried that and several other options earlier, but retried it again without the cat and -if or +2 options. Although it still displayed incorrectly, it gave me some other ideas to try that can refine my explaination of what is occuring.
The "sort -k3,#" has to be used to correctly sort on the correct field without the +2 option. The # here represents both the same field number as well as other field numbers (i.e. "-k 3,3" and "-k 3,4" etc). This was also tested with and without the -df options, as well as with an additional -k1,# option.
ctrbgone3 bgone 48794 08:56:44.78
ctrbgone3 bgone 57012 08:56:29.35
ctrsharedgui2 bgone 58890 09:48:52.91
ctrsharedgui3 bgone 59396 09:49:14.33
ctrsharedgui1 bgone 64580 09:46:32.52
ctrbgone3 bgone 68052 08:57:18.26
ctrvcthree2 vcthree 53410 10:01:19.00
ctrbricktwo1 bricktwo 43064 09:06:34.97
Basically there are two observations.
First, the sort -k 3,# begins correctly but is looking at it from that point to the end of the line as the sort "field". Thus the "bgone" ids are actually sorted by user_id including the pid and time stamp, so the additional -k 1,# option never comes into play.
Secondly, the sort is not sorting strickly alphabetically even with the -df option, but is sorting alphabetically based on identical length values. Thus all five character names are sorted alphabetically followed by all six character names, then seven, eight, nine, etc.