But the Administrative mode of the port was 'trunk', NOT 'dynamic auto' or 'dynamic desireable'...so my understanding is that DTP is in that case not being used to determine the operational mode of the port.

The only time DTP isn't used is when issuing the command

#switchport nonegotiate

By "used", I mean DTP frames will not be used to determine the operational mode of the port, though I suppose they will still be sent out that port. From the DTP table:

Mode: on

Function: Puts the port into permanent trunking mode and negotiates to convert the link into a trunk link. The port becomes a trunk port even if the neighboring port does not agree to the change.

Again, given that the port was explicity configured as a trunk, I don't understand how DTP could make it's operational state as "static access"

http://www.cisco.com/univercd/cc/td/doc/product/lan/cat3560/12225see/cr/cli3.htm#wp1989134

"Internetworking devices that do not support DTP might forward DTP frames improperly and cause misconfigurations. To avoid this, you should turn off DTP by using the switchport no negotiate command to configure the interfaces connected to devices that do not support DTP to not forward DTP frames."

For the most part, I agree with your theory, however - DTP played a part on what you saw. If you had nonegotiate on the port, the port would've been trunked regardless what the other device operational state was.

Yes, but that quote is saying that a non Cisco device migh improperly FORWARD DTP frames, which of course aren't meant to be forwarded like regular frames ( similar to STP frames ). So I think that quote is cautioning against a DTP frame being sent somewhere it shoulnd't, and that fact causing a misconfiguration. It's not that suddenly DTP will behave outside of its specification because it is connected to a non Cisco device. That is my interpretation.

In the end, there are two points that make me think something other than DTP caused this:

1) The port was set statically to 'trunk'. No matter what DTP frame was, or was not received, the operational mode should not have even been 'static access'. That is according to my understaning of the DTP protocol specification.

2) A shut/no shut caused the port to come into the correct operational state. If it was DTP that sent the port into an operational state of 'static access', what possible help could a shut/no shut have been? Since no configuration or DTP changes were made, why wouldn't it have continued to be in an operational state of static access?

Because the remote device responded correctly this time ?

I guess no matter what I say here, you've made up your mind.

What you saw it's odd but the only thing that can change a normal behavior based on your config, was DTP.