I think I've found the reason behind those crashes as in the configuration posted in the earlier mail.
First the full backtrace:
Message: Process 13965 (imap) of user 105 dumped core.
Stack trace of thread 13965:
#0 0x00007fbdaa15929a __strcmp_sse2_unaligned (libc.so.6)
#1 0x00007fbdaa820c50 mail_storage_match_class (libdovecot-storage.so.0)
#2 0x00007fbdaa820cbf mail_storage_find (libdovecot-storage.so.0)
#3 0x00007fbdaa82103d mail_storage_create_full (libdovecot-storage.so.0)
#4 0x00007fbdaa8212c2 mail_storage_create (libdovecot-storage.so.0)
#5 0x00007fbdaa816cdc mail_namespaces_init_add (libdovecot-storage.so.0)
#6 0x00007fbdaa817694 mail_namespaces_init (libdovecot-storage.so.0)
#7 0x00007fbdaa82a4cd mail_storage_service_init_post (libdovecot-storage.so.0)
#8 0x00007fbdaa82c266 mail_storage_service_next_real (libdovecot-storage.so.0)
#9 0x00007fbdaa82c321 mail_storage_service_next (libdovecot-storage.so.0)
#10 0x00007fbdaa82c49a mail_storage_service_lookup_next (libdovecot-storage.so.0)
#11 0x00000000004314f0 client_create_from_input (imap)
#12 0x0000000000431968 login_client_connected (imap)
#13 0x00007fbdaa49b1c1 master_login_auth_finish (libdovecot.so.0)
#14 0x00007fbdaa49baca master_login_auth_callback (libdovecot.so.0)
#15 0x00007fbdaa49cae9 master_login_auth_input_user (libdovecot.so.0)
#16 0x00007fbdaa49cfb1 master_login_auth_input (libdovecot.so.0)
#17 0x00007fbdaa54a545 io_loop_call_io (libdovecot.so.0)
#18 0x00007fbdaa54ce68 io_loop_handler_run_internal (libdovecot.so.0)
#19 0x00007fbdaa54a726 io_loop_handler_run (libdovecot.so.0)
#20 0x00007fbdaa54a649 io_loop_run (libdovecot.so.0)
#21 0x00007fbdaa49ee3b master_service_run (libdovecot.so.0)
#22 0x0000000000431efb main (imap)
#23 0x00007fbdaa0ea291 __libc_start_main (libc.so.6)
#24 0x000000000040c6da _start (imap)
GNU gdb (GDB) 7.12
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-pc-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/.
Find the GDB manual and other documentation resources online at:
http://www.gnu.org/software/gdb/documentation/.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/lib/dovecot/imap...done.
[New LWP 13965]
Core was generated by `dovecot/imap'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x00007fbdaa15929a in __strcmp_sse2_unaligned () from /usr/lib/libc.so.6
(gdb) up
#1 0x00007fbdaa820c50 in mail_storage_match_class (storage=0xdc5800, storage_class=0x7fbdaab715c0
So the first argument passed to strcmp() was NULL. The offending part of code is:
if ((storage->class_flags & MAIL_STORAGE_CLASS_FLAG_UNIQUE_ROOT) != 0 && strcmp(storage->unique_root_dir, (set->root_dir != NULL ? set->root_dir : "")) != 0) return FALSE;
The 2nd argument is sanitized explicitly, but the first is not - and apparently it can be NULL as well. Adding same check to the 1st argument stopped segfaults and both shared namespaces seemed to be working correctly - so user 'msl' could see/subscribe shared folders from user 'nnm' and vice versa (both mailboxes being of different format). While this was enough here, something else might be needed to make it fully correct (the original strcmp() invocation would suggest that the 1st argument should never be NULL).