Consider the following steps:

1. Suppose there is an encrypted table "t"
2. Take a base backup of the database
3. Create a table like t and name it tmp_t
4. Rename t to z_t and tmp_t to t
5. Start an increment backup, while the increment backup is ongoing, execute
optimize table on t (make sure this is executed after copying t to the backup)
6. Restore the incremental backup and start the server.

When we try to access z_t table to t_prime, we get the following error:
errno: 155 "The table does not exist in the storage engine"

Further, if the z_t is not empty, we get the following error during incremental backup restore:

{{2023-04-12 15:07:28 4631856640 [Note] InnoDB: Starting final batch to recover 56 pages from redo log.
2023-04-12 15:07:28 4631856640 [ERROR] [FATAL] InnoDB: Trying to read page number 4 in space 4, space name test/z_tmp_u1332929658s, which is outside the tablespace bounds. Byte offset 0, len 16384
230412 15:07:28 [ERROR] mysqld got signal 6 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.

To report this bug, see https://mariadb.com/kb/en/reporting-bugs

We will try our best to scrape up some info that will hopefully help
diagnose the problem, but since we have already crashed,
something is definitely wrong and this may fail.

Server version: 10.2.44-MariaDB-debug
key_buffer_size=0
read_buffer_size=131072
max_used_connections=0
max_threads=1
thread_count=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 5466 K bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

Thread pointer: 0x0
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
stack_bottom = 0x0 thread_stack 0x49000
Assertion failed: (m_files.empty()), function ~CreateTracker, file /Users/thejaka.kanewala/git/mysql/vagrant-build/thejaka-server/storage/innobase/sync/sync0debug.cc, line 1549.
0 mariabackup 0x0000000108a6864c my_print_stacktrace + 60
0 mariabackup 0x0000000107cf5ec0 handle_fatal_signal + 896
Assertion failed: (m_files.empty()), function ~CreateTracker, file /Users/thejaka.kanewala/git/mysql/vagrant-build/thejaka-server/storage/innobase/sync/sync0debug.cc, line 1549.
0 libsystem_platform.dylib 0x00007ff81b4badfd _sigtramp + 29
0 ??? 0xf6b5c00840001004 0x0 + 17777326245780918276
Assertion failed: (m_files.empty()), function ~CreateTracker, file /Users/thejaka.kanewala/git/mysql/vagrant-build/thejaka-server/storage/innobase/sync/sync0debug.cc, line 1549.
0 libsystem_c.dylib 0x00007ff81b3f0d24 abort + 123
Assertion failed: (m_files.empty()), function ~CreateTracker, file /Users/thejaka.kanewala/git/mysql/vagrant-build/thejaka-server/storage/innobase/sync/sync0debug.cc, line 1549.
0 mariabackup 0x0000000108876d14 _ZN2ib5fatalD2Ev + 84
0 mariabackup 0x0000000108876d65 _ZN2ib5fatalD1Ev + 21
0 mariabackup 0x00000001084a1a18 _Z6fil_ioRK9IORequestb9page_id_tRK11page_size_tmmPvS6_b + 3256
0 mariabackup 0x00000001084018ba _ZL17buf_read_page_lowP7dberr_tbmm9page_id_tRK11page_size_tbb + 1450
0 mariabackup 0x00000001084037da _Z19buf_read_recv_pagesbmPKmm + 938
0 mariabackup 0x000000010862755c _ZL17recv_read_in_area9page_id_t + 444
0 mariabackup 0x0000000108626723 _Z26recv_apply_hashed_log_recsb + 1779
0 mariabackup 0x00000001087d155a _Z34innobase_start_or_create_for_mysqlv + 12186
0 mariabackup 0x0000000107c6aa8d _ZL11innodb_initv + 13
0 mariabackup 0x0000000107c630a7 _ZL23xtrabackup_prepare_funcPPc + 2279
0 mariabackup 0x0000000107c59ef8 _ZL8main_lowPPc + 1784
0 mariabackup 0x0000000107c5966b main + 603
0 dyld 0x00000001140cd52e start + 462
The manual page at https://mariadb.com/kb/en/how-to-produce-a-full-stack-trace-for-mysqld/ contains
information that should help you find out what is causing the crash.
Core pattern: /cores/core.%P
......}}