Kris, that's the expected behavior actually. With multi level partitioning you are creating partitions within a partition (also called a sub partition), so you would still be at the mercy of the 1000 partition limit per table.
Let's analyze
CREATE COLUMN TABLE "MOLJUS01"."TEST_PARTITION"
("COL1" NVARCHAR(10), "COL2" NVARCHAR(10), "COL3" NVARCHAR(10));
single part created
ALTER TABLE "MOLJUS01"."TEST_PARTITION" PARTITION BY HASH ("COL1") PARTITIONS 5;
5 parts created
--reset table partitioning
ALTER TABLE "MOLJUS01"."TEST_PARTITION" MERGE PARTITIONS;
ALTER TABLE "MOLJUS01"."TEST_PARTITION" PARTITION BY HASH ("COL1") PARTITIONS 5, RANGE("COL2")
(PARTITION '20150101' <= VALUES < '20150106',
PARTITION '20150106' <= VALUES < '20150111',
PARTITION '20150111' <= VALUES < '20150116',
PARTITION '20150116' <= VALUES < '20150121',
PARTITION '20150121' <= VALUES < '20150126',
PARTITION OTHERS);
30 parts created
From this query you can see it more clearly. PART_ID is the unique counter of partitions, while PARTITION indicates the main partition and SUBPARTITION indicates the sub levels. This is similar but not the same look as seen in the run time view of the table.
SELECT * FROM "SYS"."M_CS_PARTITIONS"
WHERE "TABLE_NAME" = 'TEST_PARTITION'
There are 30 partitions total for this table.
So in a nutshell, the system behavior looks correct.
Happy HANA,
Justin