Eureka editor - mismatched sectors

Looking at Eureka's source code, it seems that mismatched sectors are what's found by this function:

void Sectors_FindMismatches(selection_c& secs, selection_c& lines)
{
  //
  // Note from RQ:
  // This is a very simple idea, but it works! The first test (above)
  // checks that all Sectors are closed. But if a closed set of LineDefs
  // is moved out of a Sector and has all its "external" SideDefs pointing
  // to that Sector instead of the new one, then we need a second test.
  // That's why I check if the SideDefs facing each other are bound to
  // the same Sector.
  //
  // Other note from RQ:
  // Nowadays, what makes the power of a good editor is its automatic tests.
  // So, if you are writing another Doom editor, you will probably want
  // to do the same kind of tests in your program. Fine, but if you use
  // these ideas, don't forget to credit DEU... Just a reminder... :-)
  //
  secs.change_type(OBJ_SECTORS);
  lines.change_type(OBJ_LINEDEFS);
  if (NumLineDefs == 0 || NumSectors == 0)
  	return;
  FastOpposite_Begin();
  for (int n = 0 ; n < NumLineDefs ; n++)
  {
    const LineDef *L = LineDefs[n];
    if (L->right >= 0)
    {
      int s = OppositeSector(n, SIDE_RIGHT);
      if (s < 0 || L->Right()->sector != s)
      {
        secs.set(L->Right()->sector);
        lines.set(n);
      }
    }
    if (L->left >= 0)
    {
      int s = OppositeSector(n, SIDE_LEFT);
      if (s < 0 || L->Left()->sector != s)
      {
        secs.set(L->Left()->sector);
        lines.set(n);
      }
    }
  }
  FastOpposite_Finish();
}

It seems, if I understand what's happening in there, that it looks at what sector the line is facing (s = OppositeSector(n, SIDE_RIGHT or SIDE_LEFT), and checks whether that's the sector the line's side officially belongs to (L->Right() or Left()->sector). If they don't match, you get a mismatched sector error. So check the lines of the mismatched sectors one by one to find the ones that don't make sense.

Thanks @Gez.

That makes sense with what I see in the editor:

The sec: value

I did not realise what this meant  this before,  so I solved it by removing and then rebuilding the affected sectors rather than copy/paste. The problems have now gone away.

Thanks for looking into this.

Oooh! This looks like a bug in Eureka.

I replicated the situation, with @Gez comments above in mind.

On copying the connected sector, I did indeed see the connected linedef showing up with an incorrect sector ref:

This is on Check/ALL.

Sector on left is 203 and right (copied one) is 206

Now, the highlighted linedef on right has an incorrect sector reference, back to source neighbour sector 202:

From @Gez useful post above, I flipped the linedef and changed the sec: ref to 206. The tests still failed. It looks like the back sidedef flags (which is now not connected to anything) should be removed - but they are not and I don't see how to remove them in the UI.

I also just tried the same copy/paste of this sector in DB2 on Windows. The copied sector did not exhibit the same issue as it does in Eureka - the linedef did not have attributes for both sides and there did not seem to be any mismatched sector refs.. The copied sector has all single sided linedefs and there are no errors on testing. 

Here, the corresponding DB2 props for the same linedef:

I therefore definitely think it is a copy bug in Eureka.

Please consider this question resolved.