In short, to maybe clear things up a little.
If SQL has to take an X lock on a row, it does the following:
Take an IX lock on the table - meaning some resource within this will be locked X
Take an IX lock on the page - meaning some resource within this will be locked X
Take an X lock on the row.
This is for ease of checking lock compatibility. If all SQL had was an X lock on the row without any of the intents, and another process wanted an S lock at the table level, SQL would have to check locks on every single row in the table before it would know whether or not the table S lock could be granted. That could take a while
With the IX lock at the table level, it's a single check. Can an S lock be taken on this table? No, S is not compatible with IX.
As another example, let's say that there's the same X and IX locks, and something wants an S lock on a page.
First thing, SQL tries to take an IS lock on the table. That succeeds, IS and IX are compatible.
Then SQL tries to take the S lock on the page. If it's the same page that's locked IX, that S lock will have to wait. If it's a different page (hence has no locks), the lock is taken, and the table ends up with an IX and an IS at the table level, an S and an IX on different pages in the table and an X lock on a row
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
We walk in the dark places no others will enter
We stand on the bridge and no one may pass