I've always believed from documentation that only single field sparse index were supported.
Doing quick testing, it turns out:

• compound sparse index creates fine
• the behavior is that it is only sparse if all fields are non existent

I feel like the behavior is not useful at all: it's rare that all fields are absent and thus it mostly behaves like a non-sparse.
The more common use case is as follows:

• a sparse field tells if doc should be included in index
• compound on other fields to do further matching an sorting, like time etc

Say I'm working on reconciliation software: 99% of my records are matched and 1% non matched.
I need to do fast operations on non-matched items that may include complex matching and sorting.
Right now if I want to compound the index, all 100% records will be in index tree.
Ideally I just have a sparse flag "unmatched: true" and can compound freely

and obtain an index that's 99% smaller.
Today the only solution is to somehow encode information into the "unmatched" field.