I highly suggest reading some of the docs at
http://www.microsoft.com/exchange/library to get a bit more up to speed on
the details.

Exchange handles multiple instances of the data stores as a single server.
In older technology, there was one mail store per server.  In SQL and
Exchange 200x they introduced multiple stores per server.  In 200x, you can
have up to 20 of them [1] max. They are all seen as a single server and they
all share the same GAL, PF hierarchy, F/B time, etc. Whether or not you put
them on different disks depends on your needs and configuration. It's I/O
type is random R/W typically with a 3:1 r:w signature (disk perspective)
after it normalizes. Because each company is different and because the
signature changes as you grow data sizes, it's hard to predict based on the
situation you're in but that would be the mix to plan for initially. A goal
if you will.

That said, separating out the I/O types typically done based on priority.
The priority is often set based on ROI of performance vs. cost. What I've
typically seen goes something along this order:

1) Log files: best ROI if you separate the log files (per SG) to their own
spindles.  Highly write intensive (~95% write wouldn't be surprising if not
a little conservative)
2) MTA/SMTP Queue files (I'm showing my age with this stuff, because SMTP
Queues are the recent version ;) Typically very write intensive because
Exchange will spool each message to the disk before processing further. Some
variation occurs, but you can expect 1:7 r:w I/O types
3) tmp files.  Exchange uses these when it needs some scratch space.
Separating this out can be useful for added performance
4) Store DB's (EDB and STM files together) can and often should be separate.
Tends to be random r/w so putting all 20 on the same set of physical disks
can be workable.  As the db's grow, it might be best to group them based on
storage group or even to take it to the next level and separate them out if
the stores are really large and highly utilized.

There's some good docs about troubleshooting performance that would be
worthwhile for you to read along with the deploying and design docs at that
link.  Else you would hire a consultant to help out (that's folks like me
;)

Don't forget to take your AD GC's into account as well as your back/restore
requirements. You'll want those in the planning process up front vs. as an
afterthought to save time and money.

Does that help?

Al

[1] active on a server at a time.  I'm not talking about RS DB's.  There's
more information in the docs at that link.