For several users, the network configures each user having the same code but different frame timing and, thus, users can be transmitted on the single code source. The original timing is thus retained which avoids the need to adjust timings based on Release 99 power control loop implementation.
During slots where the DPCCH is not transmitted, the NodeB cannot estimate the uplink signal-to-interference ratio for power-control purposes and there is no reason for transmitting a power control bit in the downlink. Consequently, the UE shall not receive any power control commands on the F-DPCH in downlink slots corresponding to inactive uplink DPCCH slots.
There are some restrictions for FDPCH. It is not usable with services requiring data to be mapped to the DCH, such as AMR speech calls and CS video. Also, the lack of pilot information means that a method like feedback-based transmit diversity (closed loop mode) is not usable. The use of closed loop diversity is based on user-specific phase modification, wherein pilot symbols would be needed for verification of the phase rotation applied. On the other hand, when utilizing the F-DPCH, SRBs can benefit from high data rates of HSDPA and reduce service setup times remarkably
Finally, as you may have already figured out, by using F-DPCH the cell capacity has been improved and at the same time for same number of users, the interference has gone down significantly.
In Release 7, Rel-6 limitation has been removed. In R6, for a given UE in soft handover the TPC from all F-DPCH had to have the same offset timing. In R7, F-DPCH (TPC bits) can have different timing from different cells. This is possible due to introduction of 9 new F-DPCH slot formats (slot format 0 is the legacy F-DPCH slot format). The RRC signalling is done seperately for slot formats from the RNC to each of the cells.
You may also be interested in this Ericsson paper titled "The effect of F-DPCH on VoIP over HSDPA Capacity". Available here.