When cursor->remove() is called and succeeds, it leaves the cursor positioned on the deleted record. After writing a test that exercises different operations on a cursor immediately following a successful remove(), I found two divergences between layered and ASC cursors behavior:

1. Calling remove() immediately after a previous remove() correctly returns WT_NOTFOUND, but it does not clean up the cursor position properly. As a result, a subsequent next() call returns the key following the deleted key, rather than starting from the beginning.
2. Calling modify() on a deleted record crashes instead of returning WT_NOTFOUND.

The behavior should be aligned with that of the ASC cursor, which is also what the new test verifies.

Please see the attached test file for additional details.