This concerns screened only, not any released versions.

The symptom is that when `darcs rebase pull` suspends some patches, 
we sometimes get a warning about "conflicts with unrecorded changes" 
even if we did not have any such unrecorded changes in the first 
place. Moreover, aborting the operation when prompted leaves lots of 
unrecorded changes in the working directory.

It seems that the call to `unrecordedChanges` inside of 
tentativelyMergePatches gives wrong results. Looking for possible 
culprits led me to

  patch b9117bbe58bad86463ed390c75aba9a2539a2c30
  Author: Ben Franksen <ben.franksen@online.de>
  Date:   Tue Mar  2 11:48:56 CET 2021
    * get rid of "nasty hack" in applyPatchesForRebaseCmd

finalizeRepositoryChanges has the side effect of updating the index,  
which can have an effect on the unrecorded changes, since we use the 
index to filter the working tree. And indeed the problem does not 
appear if --ignore-times is passed i.e. if we disable the index.

Fixed in patch2288

The following patch sent by Ben Franksen <ben.franksen@online.de> updated issue issue2700 with
status=resolved;resolvedin=2.18.1

Hash: 7fddbdbe9b2c94b476b338ac9956890f70118f99
Author: Ben Franksen <ben.franksen@online.de>
* resolve issue2700: rebase pull spurious conflicts with unrecorded

  The culprit here was

  patch b9117bbe58bad86463ed390c75aba9a2539a2c30
  Author: Ben Franksen <ben.franksen@online.de>
  Date:   Tue Mar  2 11:48:56 CET 2021
    * get rid of "nasty hack" in applyPatchesForRebaseCmd

  Finalizing a transaction also updates the index, which has an influence on
  the result of unrecordedChanges (which is called by tentativelyMergePatches)
  because the index is used to filter the working tree (unless --ignore-times
  is in effect). We eliminated a finalize/revert pair, which means we must
  call 'updateIndex' manually here. We normally don't change the working tree
  from inside a transaction, so this is a somewhat special situation.