rccpgm,
Thank you for your response. It seems my SFP-T transceivers while snug are not too large to stack but I have seen older copper transceivers which are much larger. The stack restriction makes sense in that context.
Paragraph 3 may not have been worded as well as it could have been, but is substantially accurate. The ports on FPC 1 work with copper transceivers but not on FPC 0 - with one exception: ge-0/1/0.
I revisited the problem using a managed gigabit switch on the remote end of the link. While keeping the remote port constant, I alternated the physical connection on the EX4600 between ge-0/1/0 and ge-0/1/1. In every case, ge-0/1/0 worked and ge-0/1/1 did not but the remote link stayed up (while connected) at 1000/full.
I stripped out the auto-negotiation and speed commands from ge-0/1/1 but this had no effect.
Finally, I did as you suggested, disabled auto-negotiation on both sides of the link and hard set 1000/FDX. When I did that, the other side of the link went down completely - no more link lights. If I understand the Juniper documentation correctly, you can't hard set the speed and duplex on EX4600 1G ports. Auto-negotiation is enforced on these ports even if the commands to hard set speed and duplex are present.
I have never seen this kind of behavior before on any switches I have used, although I am not very experienced with Juniper products. I have seen cases where transceivers did not work because they required a newer software release on the switch, but this was a global condition not limited to specific switch ports. Even so, I am beginning to suspect a bug in the installed version of JunOS. I've opened a JTAC case. We'll see where that leads.
Thanks again.