By "SS pin" you actually mean CS pin (chip-select). The pin on the ATmega is called "SS"
because it is used for "slave select" when the microcontroller is actiing as a SPI slave
device.
Any pin can be used as a chip-select, its not directly connected to the SPI hardware.
However pin 10 must be configured as an OUTPUT for the SPI hardware to work,
so its normally used as a CS pin if SPI is employed.
The problem with many SPI libraries is that SPI is not one standard. Its not even a
standard, come to that. You can have MSB-first or LSB-first, there are 4
combinations of clock polarity and phase, the data rate can be selected from about
7 possibilities.
Thus with several SPI devices an SPI library should be checking to see for every call
whether the SPI hardware needs to be reconfigured for the slave in question. I don't
think any of the SPI libraries out there do this, so in practice you are limited to connecting
devices with the same data rate, polarity, endianness, etc...
Also various "SPI" devices are not SPI (they do not completely ignore the SCLK line
when their CS is high, for instance, or fail to set MISO to tri-state). And more fundamentally
some slow devices are not designed to handle a fast clockspeed on SCLK, so connecting a
slow device and a fast device on the same SPI bus could cause issues.
And lastly the real "gotcha" - by default Arduino pins are inputs, and float.
Thus with several devices on SPI with separate CS lines, when you power up they can
think they are being selected (CS happens to be LOW). This means that several may
start to drive the MISO line simultaneously and fight each other.
(Furthermore they are susceptable to any noise on the SCLK / MOSI lines which
are also floating at this point).
A wise precaution is to add a physical pull-up resistor to each CS line (internal pull-up
is too late). That way you know the device will start up in a known state and they won't
try to drive the SPI bus before your sketch is ready.