Having run out of sensor ports, we're about to add a sensor mux. A couple of questions came to mind..

1) does the possible sampling time/rate change when moving an existing Gyro sensor from a standalone port onto a mux port? In other words, will the existing code perform any differently after changing the function call(s) to access the sensor via the mux?

2) related to the above, will there be any noticeable difference/interaction if the Gyro is being accessed via one task while other mux sensors are being read in other tasks.

Well, there are several differences I can think of.

The sampling time will be limited by the I2C speed (if not further by the mux itself).

There is no way to have multiple transactions going on with any I2C sensor (muxs included). The safest way would be to use a mutex to control the I2C calls. This would potentially present reading time differences (for example, one read might take 5ms, and the next time it might take 6-15ms (if another task is using the I2C bus)). Basically, you couldn't rely on a constant read time.

Usually when I use a gyro, I like to integrate the values. Any inconsistencies could have a dramatic response on the final value. Things such as read times, if the NXT motors have been previously powered... can all make a difference, and need to be accounted for. I would suggest you keep the Gyro on an NXT port, or else have it the only thing accessed on the I2C bus, so that you can read it whenever (unless you will only be using one task, and never attempting to make more than one call at a time).

I haven't used ROBOTC enough to know what the FW handles, and what is left to the programmer as far as multiple I2C calls... and I don't have a HT sensor mux (as I assume you are talking about) to try stuff with.

We ran the gyro through the Sensor Mux before and did not have any issue with it. The only issue is that from time to time, the students may forget to turn the power of the sensor mux on and did not realize it until autonomous failed miserably.

A lot of RobotC functions are not thread-safe. In fact, I recall reading some posts about RobotC doesn't support calling a function from different tasks. Even if RobotC supports calling a function from different tasks, you still need to determine if the function is written such that it is thread-safe (e.g. no accessing global resources etc). I assume you are calling Xander's Gyro driver? If so, Xander can comment on if his Gyro driver is thread-safe.
A lot of students don't understand how to do multi-tasking programming properly anyway. That's why we have been avoiding RobotC tasks altogether. We do our own "cooperative multi-tasking" which is a lot safer and don't have all the gotcha's of preemptive multi-tasking.

Our library has a gyro module that does integration. Our integration doesn't depend on time consistency of when the integration is called. In other words, if preemptive multi-tasking decided to call our integration function late or even skip a time slice, the integration will still integrate correctly because it reads its own timestamp and use it for the dT calculation. As long as the integration function is called frequent enough, it is sufficiently accurate.