What I decided to do was just stop the ray at the portal itself instead of having it bounce through. There were a number of reasons I decided to do it this way instead of having it bounce around through the portals.
First, it just looks better. The bouncing rays, especially in the mirror, were distracting. They were certainly cool looking, but I could tell pretty quickly that this would get old soon.
Second, it was just fine from the user's point of view. The way the laser works locally, the point of the laser pointer is at the location that the camera pointer intersects the portal, but this is also where the point of the target object lives. So it looks like - from the perspective of the owner of the pointer - he is picking the actual object.
Third, I realized that I would have to perform the equivalent of an inverse kinematic computation when the mouse was down. The reason for this was I knew where the pointer stars in space 1, and I know where it ends in space n, and doing the forward computation is actually how I determine the location of the initial end point. The problem is, I stop doing this forward test when the pointer button is down, given that I already have the selected object and it is up to IT to determine what location on the object is hot. Thus, we need to compute it backwards. Why is this hard? You need to keep track of all the portals you jumped through going forward, then you have to compute a line back through these portals using the inverse transforms of each - but you need to ensure that the result is a straight line in this multi-portal transition space. This is an exercise left for the reader. And remember, I won't use it anyway, because I didn't think it was very pretty.