This was tested with: my build of yesterdays master (release with asserts enabled); yesterdays build bot build. Assert failure was reliably reproducible with my build. Crashes - unreliable with both configurations. The only thing that was modified in my build - undefined NDEBUG to enable asserts. I'm not aware of a better way to get asserts in the release build. I will make a more "official" debug build and test with that, as well as search for other clues. Will get back later with the results after all the rebuilds (it will take ages on my cpu).

Updated and reset git and svn. Deleted user preferences directory. Rebuilt both Debug and Release in a clean directory. Only cmake changes: enabled CUDA and OptiX.

First try (all clean)
Debug: no crash, no assert.
Release: no crash.
Conclusion: Unreproducible in the stock Debug and Release builds (crash may or may not be there, but it's hard to reproduce in any case).

With modification

diff --git a/source/blender/draw/intern/draw_cache_extract_mesh.c b/source/blender/draw/intern/draw_cache_extract_mesh.c
index f1a7ab8c9d8..e2061c34b60 100644
--- a/source/blender/draw/intern/draw_cache_extract_mesh.c
+++ b/source/blender/draw/intern/draw_cache_extract_mesh.c
@@ -674,6 +674,10 @@ static void extract_tris_finish(const MeshRenderData *mr, void *ibo, void *_data
   GPU_indexbuf_build_in_place(&data->elb, ibo);
   /* HACK: Create ibo sub-ranges and assign them to each #GPUBatch. */
   if (mr->use_final_mesh && mr->cache->surface_per_mat && mr->cache->surface_per_mat[0]) {
+    if (mr->cache->surface_per_mat[0]->elem != ibo) {
+      printf("mr->cache->surface_per_mat[0]->elem: %x; ibo: %x\n", mr->cache->surface_per_mat[0]->elem, ibo);
+      printf("mr->cache->surface_per_mat[0]->elem->data: %x\n", mr->cache->surface_per_mat[0]->elem->data);
+    }
     BLI_assert(mr->cache->surface_per_mat[0]->elem == ibo);
     for (int i = 0; i < mr->mat_len; i++) {
       /* Multiply by 3 because these are triangle indices. */

Debug: no crash, no assert, no output.
Release: no crash, but got reliable output on each Alt+D:

Read prefs: C:\Users\vvv\AppData\Roaming\Blender Foundation\Blender\2.90\config\userpref.blend
found bundled python: C:\Users\vvv\Documents\HOME\blender\blender-source\build\bin\Release\2.90\python
mr->cache->surface_per_mat[0]->elem: c29d47e8; ibo: c29d4068
mr->cache->surface_per_mat[0]->elem->data: c29d4068
mr->cache->surface_per_mat[0]->elem: c29d7668; ibo: c29d7b28
mr->cache->surface_per_mat[0]->elem->data: c29d7b28
mr->cache->surface_per_mat[0]->elem: afb27b98; ibo: c300d888
mr->cache->surface_per_mat[0]->elem->data: c300d888

Conclusion: The condition only reliably happens in the release builds, where asserts are disabled.

Side notes
Release without NDEBUG is highly recommended for testing this and other possibly related issues. I've stumbled onto this issue when poking around on something like T78054. While at it, I've noticed a lot of unreproducible issues related to the different draw_cache_extract.c functions. I've got a strong feeling that it's related to the multithreded executions of those functions. The actual crashes happen all over the place. Sometimes it's corrupted data (especially frequently noticed with custom data, but that's maybe because I was looking mostly into it), sometimes attempts do double free, sometimes just pure randomness. It would be cool to be able to isolate all the data that may be accessed cross-thread in some getters/setters and lock it with mutexes, but the scope of it is huge, and it's not feasible with current data structures. Anyway, all this may not even be related to the current issue.