According to the CPLEX user's manual:

After a model has been read (or created), the first call to populate will carry out both the first and second phase. In the general case, subsequent calls to populate will re-use stored information and proceed with the continuation of the second phase. The first phase will be re-computed if:

• the value of the pool intensity parameter has increased between successive calls of populate;

• any filters have been deleted.

This is in fact the behavior I observe when calling populate twice consecutively in the interactive optimizer. When I call it twice consecutively from Java, however, CPLEX repeats the first phase, resulting in identical output from the two calls (no progress processing the rest of the search tree). I confirmed this with both CPLEX 12.8 and the beta of 12.9, running the same problem from Java and in the interactive optimizer. In the Java code, the two invocations of populate() are on consecutive lines, with nothing in between.

I'm attaching the log from the Java code (which includes the underlying problem data at the top). The problem is a small knapsack, which CPLEX easily solves at the root node. This was generated with the 12.9 beta, but the 12.8 output appears to be identical. Either this is a bug or the user manual description needs to distinguish between how things work in the interactive optimizer and how they work in the APIs. (My guess is that it's a bug.)

If you want the Java code (which is a bit verbose, as it also contains other methods for generating solutions), I'll be happy to share it.

When you run from the interactive, do you also set CPX_PARAM_ADVIND=0?

If you set CPX_PARAM_ADVIND=0 then you ask CPLEX not to use any advanced starting information. In populate this is interpreted as starting from scratch with phase I.

I can reproduce your problem here with CPX_PARAM_ADVIND=0 but as soon as I leave that parameter at its default value, the second call to cplex.populate() starts with phase II.

Oops! That was the problem. The Java code turned off warm starts (not sure why -- it's old code). My bad.