Confused on your post. Do you mean to say that you have a multi level partition defined on the table with a hash-range option? This would indicate to me that you always intend to use a GUID value when querying the table, otherwise any advantage of the partitioning in the first level is gone.
In general, for range partitioning you need to define the intervals up front. There will always be an OTHER interval that will catch anything that doesn't meet currently existing intervals. So no need to worry that you will "lose" data, it will just fall into an un optimized bucket. However, when you add new range partition intervals, the OTHER bucket will be split apart if you add intervals that now match data present there.
No performance impact if you have empty intervals, and of course no (maybe a tiny bit) memory will be consumed since their empty.
I would make partition analysis a component of some periodic system activities.
Regards,
Justin