Great!

As Hans mentioned, I would suggest adding a test for:

• Moving an item to the end in a list, and asserting that the newIndex is as expected
• Moving an item to the start of a list, and asserting that the newIndex is as expected

I think this can be simplified. It seems as if endIndex is off by one, whenever we move an item towards the end of the list, due to us having a finalDropArea in the end of the list.

I think doing something like this will be more readable:

diff --git a/packages/flutter/lib/src/material/reorderable_list.dart b/packages/flutter/lib/src/material/reorderable_list.dart
index e11ca1273..70eaeb095 100644
--- a/packages/flutter/lib/src/material/reorderable_list.dart
+++ b/packages/flutter/lib/src/material/reorderable_list.dart
@@ -392,7 +392,9 @@ class _ReorderableListContentState extends State<_ReorderableListContent> with T

     // Drops toWrap into the last position it was hovering over.
     void onDragEnded() {
-      reorder(_dragStartIndex, _currentIndex);
+      final int endIndex = _currentIndex > _dragStartIndex ?
+        _currentIndex - 1 : _currentIndex;
+      reorder(_dragStartIndex, endIndex);
     }

     Widget wrapWithSemantics() {
@@ -401,11 +403,9 @@ class _ReorderableListContentState extends State<_ReorderableListContent> with T

       // Create the appropriate semantics actions.
       void moveToStart() => reorder(index, 0);
-      void moveToEnd() => reorder(index, widget.children.length);
+      void moveToEnd() => reorder(index, widget.children.length - 1);
       void moveBefore() => reorder(index, index - 1);
-      // To move after, we go to index+2 because we are moving it to the space
-      // before index+2, which is after the space at index+1.
-      void moveAfter() => reorder(index, index + 2);
+      void moveAfter() => reorder(index, index + 1);

       final MaterialLocalizations localizations = MaterialLocalizations.of(context);

Edit: I see now that the current behavior seems to be expected and that the documentation already mentions this, see theReorderCallback: https://api.flutter.dev/flutter/material/ReorderCallback.html

This change is a breaking change to the API, and it will cause internal tests to break. See the page Handle breaking changes for how to proceed with this change. An idea is to put this behind an opt in flag (for example ReorderableListView.fixOnReorderEndIndex = false) for now until we can migrate those customers to avoid this change being reverted.

See this PR for an example for how we can add a flag (shouldSnackBarIgnoreFABRect ) to opt in behaviour: https://github.com/flutter/flutter/pull/50597/files

See also the same PR for how an migration guide was added to help future developers:
#50597

At first, thank you for your review. So i will try to sum things up that need to be done:

1. Add a better Description for this PR
2. Add the opt-in flag
3. Rollback the commited test, to restore the current behaviour (with flag set to false)
4. Add new tests, that use the opt-in flag
5. Add the suggestet tests (move item to the end, move item to the start)
6. Add a migration guide

That's right, great, thanks!

I am currently a bit stuck on the tests. There are very much tests, that are testing the reordering mechanisms in several constellations (like LTR, RTL, vertical, and so on) . Should i just add some basic tests, that demonstrate the new behaviour, when the fixOnReorderEndIndex flag is set, or should i cover all those cases?

I think adding just one or two regression tests is good enough, to confirm the correct behaviour. The old tests would cover the rest.

For example:

• Test for moving an item downwards with the correct onReoder endIndex.
• Test for moving an item upwards with the correct onReoder endIndex.
• Test that when you are just dragging and item into the same spot as it was before, ensure that onReoder is not called. Then you can also add a comment:
  ``// This is a regression test for https://github.com/flutter/flutter/issues/24786.`

You can also reuse the old tests, by adding a for loop to test the behaviour with your flag and without. Perhaps that makes it easier?

An example of that is here: https://github.com/flutter/flutter/blob/master/packages/flutter/test/painting/gradient_test.dart#L819