Comment 5 for bug 901069

> The reason is that when a function defined on another mesh, it is
> interpolated locally to the mesh of the function space used to define
> the form (which in this case is the function space into which the
> function is being projected). So 0, 1, 0, 0, 0 will be interpolated
> into 0, 0, 0 and then projected.

I checked code generated by project(.., form_compiler_parameters={'representation': 'quadrature'}). Here's relevant piece of compiled rhs of projection to CG1:
_____________________________________________________________________________
    // Loop quadrature points for integral.
    // Number of operations to compute element tensor for following IP loop = 24
    for (unsigned int ip = 0; ip < 2; ip++)
    {

      // Coefficient declarations.
      double F0 = 0.0;

      // Total number of operations to compute function values = 4
      for (unsigned int r = 0; r < 2; r++)
      {
        F0 += FE0[ip][r]*w[0][r];
      }// end loop over 'r'

      // Number of operations for primary indices: 8
      for (unsigned int j = 0; j < 2; j++)
      {
        // Number of operations to compute entry: 4
        A[j] += FE0[ip][j]*F0*W2[ip]*det;
      }// end loop over 'j'
    }// end loop over 'ip'
____________________________________________________________
FE0 are basis (of new element) values at quadrature points. W2 are quadrature weights.

It is obvious that form requires dof values w[][] of coefficient. But these are dofs with respect to new element. So they must be computed by interpolation in DOLFIN.

So it seems that projection is implemted with pre-interpolation in DOLFIN because UFC requires it. Sounds like a major flaw in UFC.