Does it go away if you set "Number of threads" to 1 in prefs?

Yes, the manipulation of threads removes this problem. It also helps the selection options: "gamma hack". The problem appears when you set the number of threads greater than 2 :-)

Yes indeed.

Actually, all point ops seem affected.

What does "gamma hack do" to the behavior of this?

This must be an old - or recently introduced, concurrent access bug in GeglBuffer, where due to racy updates to tiles some results are lost. That bug should be fixed - but improving how the slicing for the different threads is done might also eliminate many such tile acccess concurrency problems.

Haven't tried "gamma hack" but I guess adding more ops to the graph
doesn't make it better.

Now after rebuilding with some totally irrelevant cleanup i can't
reproduce this any longer, and i tried hard...

This issue was caused by a number of unrelated reasons.  It *should* be fixed in master now, by

commit 5f4414f0261778644ba96db98cb9d0ea09ff6a6a
Author: Ell <ell_se@yahoo.com>
Date:   Fri Jul 21 08:20:56 2017 -0400

    tile-backend-swap: make thread safe; move more work to writer thread
    
    Make the swap tile backend thread safe, by adding locks as necessary,
    and by moving more of the work to the writer thread, to avoid having
    to synchronize.
    
    In particular, all reader threads share the same file destrcriptor,
    so they must not try to read from the swap in parallel.  Likewise,
    all manipulation of the gap list has to be synchronized, and was
    moved to the writer thread.  This has the additional benefit that
    storage reclamation for dead entries now happens in the writer thread,
    before any outstanding write operations are performed, while, in turn,
    storage allocation also happens in the writer thread, right before an
    entry is written to the swap; this helps minimize the gaps between swap
    entries.
    
    Additionally, TILE_GET commands for tiles that are queued for writing
    now return a COWed copy of the queued data, instead of a new copy.
    
    This fixes ceratin artifacts in multithreaded programs.  See
    bug #784907.

 gegl/buffer/gegl-tile-backend-swap.c | 589 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++--------------------------------------------------------
 1 file changed, 324 insertions(+), 265 deletions(-)

and

commit 64c691c852b4baeb85fd2b6881df3c0e9226e8ab
Author: Ell <ell_se@yahoo.com>
Date:   Fri Jul 21 08:59:55 2017 -0400

    tile-handler-cache: don't trim still-in-use tiles
    
    When trimming the cache, don't remove tiles whose reference count is
    greater than one, and are therefore still in use.  Otherwise, if the
    same tile is requested again, a different tile object might be
    returned, resulting in two different tile objects referring to the
    same tile.  If both tile objects are used to modify the tile data,
    then the changes of only one of them are going to be comitted.
    
    Note that, as a result, we never free hot tiles, since their reference
    count is always greater than or equal to two.  This commit effectively
    reverts commit 8c60f31f18ec3e91f56b4ababefef75573118478, since it's
    no longer necessary.
    
    While this problem is not multithreading-specific, it's most likely
    to occur in multithreaded programs.  See bug #784907.

 gegl/buffer/gegl-tile-handler-cache.c | 126 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-----------------------------------------------
 1 file changed, 78 insertions(+), 48 deletions(-)

I'm closing this bug for now, because I can't reproduce it anymore.  It's entirely possible that there are other issues with similar symptoms lurking around.  Feel free to reopen if needed.

*** Bug 774863 has been marked as a duplicate of this bug. ***

*** Bug 759874 has been marked as a duplicate of this bug. ***