1) suppose two ports with the settings from the subject line attempt to communicate. I can't find in the 802.3 standard description of the exact behavior in such situation (obviously full-duplex won't possible at all, only HD ?)
2) suppose one port with AutoNegotiation enabled, second has fixed setting
100Mbps/full-duplex. Am I right, that auto negotiation session will fail, since the second port doesn't have on? If it so, then what settings will be applied on the first port?
It doesn't address speed-sensing, but some boilerplate about duplex negotiation - the 10HD side can be though of as being hardcoded to HD for the purposes of the below.
How 100Base-T Autoneg is supposed to work:
When both sides of the link are set to autoneg, they will "negotiate" the duplex setting and select full-duplex if both sides can do full-duplex.
If one side is hardcoded and not using autoneg, the autoneg process will "fail" and the side trying to autoneg is required by spec to use half-duplex mode.
If one side is using half-duplex, and the other is using full-duplex, sorrow and woe is the usual result.
So, the following table shows what will happen given various settings on each side:
Auto Half Full
Auto Happiness Lucky Sorrow
Half Lucky Happiness Sorrow
Full Sorrow Sorrow Happiness
Happiness means that there is a good shot of everything going well. Lucky means that things will likely go well, but not because you did anything correctly :) Sorrow means that there _will_ be a duplex mis-match.
When there is a duplex mismatch, on the side running half-duplex you will see various errors and probably a number of _LATE_ collisions ("normal" collisions don't count here). On the side running full-duplex you will see things like FCS errors. Note that those errors are not necessarily conclusive, they are simply indicators.
Further, it is important to keep in mind that a "clean" ping (or the like - eg "linkloop" or default netperf TCP_RR) test result is inconclusive here - a duplex mismatch causes lost traffic _only_ when both sides of the link try to speak at the same time. A typical ping test, being synchronous, one at a time request/response, never tries to have both sides talking at the same time.
Finally, when/if you migrate to 1000Base-T, everything has to be set to auto-neg anyway.