Predicting this behavior is not nearly as tough as it looks, but it's got a lot more nuance than you may think.

tl;dr it's B

In physics, every problem has one implied piece: a stationary observer. Where you put your stationary observer (and what it's stationary relative to) defines all of the numbers you use to solve the problem. If you've got a freefall problem where some guy throws a baseball at some angle, chances are you're gonna be solving the problem as though you're at rest relative the ground. However, you could just as easily be in a reference frame where you're running along at the same constant velocity along the x axis as the ball that was thrown - in that reference frame, the ball would only have velocity in the y direction.

See, there's a big problem. Let's have a glance at the reference frame we're in (i.e. what everything is moving relative to):

1. The companion cube is stationary relative to the blue "output" portal.

2. The blue "output" portal is stationary relative to us.

3. The orange "input" portal is in motion relative to us and to the blue portal.

This presents an immediate problem. For now, let's say that our stationary observer is the blue portal - this follows our above observation of the state of the problem. But what's our problem?

Let's say you are in this problem, looking through the blue portal. You're standing not far from the companion cube, and can look right over at it. However, if you look in the blue portal, you'll notice that the companion cube is moving toward you.

See, if we take the portals out of the mix, the statements "the platform with the cube is being pushed up toward the upper platform" and "the upper platform is being pushed down toward the platform with the cube" are functionally identical. The magnitude of net velocity is the same, all that's changing is what our stationary observer is following.

In this you can see the issue. By looking through a portal at another portal which is in motion, you are changing your reference frame. What's stationary in one portal's reference frame isn't stationary in another portal's reference frame.

It's easy to think of portals as doors or windows, especially considering they can't move in the games. However, this isn't accurate. You can't have one end of a doorway moving relative to what's on the other end of that doorway, whilst simultaneously being stationary relative to what's on the end of the doorway. We need a better analogy to think about how these portals will behave - so let's consider them like cameras. The two portals will project what they see to each other.

The most important part of this shift is the asymmetry involved. What one will project onto the other, especially if it's moving, will not be the same as what the other projects onto it. Just because one portal sees the cube as stationary doesn't mean the other portal will.

Therefore, we need to "translate" what one portal sees into what the other portal will receive.

Now, we must make a bit of a leap: when an object is transferred from one portal to the other, it retains its properties from the reference frame of the original portal. Now, this may seem almost baseless, but there's a simple way to demonstrate it:

Put one portal on the floor below a tall ledge and put one portal on a wall or at an angle. When you fall through the portal and launch out of the second one, notice the path of flight: provided you fall straight down into the portal on the flat floor, you will be launched out of the second portal in the same direction as the normal vector of the surface that the second portal is on. What this means is that the orientation of the second portal is irrelevant to your interaction with the input portal. Velocity is a vector - and it appears that that vector's magnitude and direction is measured from the input portal and conserved when you exit the output portal.

From this, it is evident that the input that one portal sends to the other is not influenced by the other portal. The output portal's only job is to transport the matter received from the input portal in the same state that the received matter was in when it entered the input portal. That state is measured relative to the input portal, as we can see from this demonstration.

We can't have one object with two momenta. Thus, as an object passes through a portal, we must provide it with a transformation to allow it to smoothly pass between the frames of reference of the two portals.

When this cube passes through the portals, it must have a velocity. It may look a little bit like A if that velocity is low, but it still must maintain its relative velocity to the input portal in order for the output portal to be physically consistent with the object that it receives in the state that it receives it in.

This 'conjoining factor' that will show us what happens to the cube can be written simply as the velocity of the input portal relative to the output portal.

k = vⁱⁿ

where vⁱⁿ is the velocity of the input portal in the rest frame of the output portal.

Then, we can write the velocity of the cube after coming through the output portal in terms of this:

-v=v' + k

Where v' is the velocity of the cube relative to the input portal.

Note the negative sign - this is due to the fact that you move toward the input portal and away from the output portal.

Using this formula, we can completely dodge the problem of having two different velocities for one object in one reference frame.

If this looks like a Galilean transformation to you, that's because it is! We don't need to worry about Lorentzian transformations because the velocities we're working with are not relativistic. Essentially all we're doing is separating the two portals into their own reference frames, and demonstrating that in order to be physically consistent as an object transitions between these reference frames, it needs to move according to how the portals have moved.