When autocommit is on, all DML should cause an implicit COMMIT. DELETE appears to be committing the data, but COMMIT is not being issued.
Regardless of autocommit, DROP TABLE should force a COMMIT. It does not.

create table t1 (c1 int)engine=columnstore;
create table t2 (c1 int)engine=columnstore;
insert into t1 values (1), (2);
insert into t2 values (1), (2);
delete from t2 where c1 in (2); // Is not committed
drop table t2; // Should also commit
insert into t1 values (3); // Causes a COMMIT for all outstanding txn, but t2 is no longer around.
// If release version, an error is generated
// if debug, an assert is hit because of two simultaneous errors:
ERROR 2013 (HY000): Lost connection to MySQL server during query
MariaDB [dml]>
this assert also orphans a lock which requires a DMLProc restart to clear.

This is problematic in that it causes goofy errors. This can really confuse a user.

This happened in 1.2 as well, but it was never detected because Server didn't debug assert under these circumstances.

After a delete, the data change shows correctly in other sessions as would be expected had a COMMIT been executed, so something is going right.