Hi Amy,
I can verify this is correct behavior in DSpace 7 because the backend (REST API) needs to apply access restrictions in a consistent manner.
Simply put, in DSpace 7, you must have READ permissions in order to "see" any object (including metadata about that object) from the REST API (and therefore also the UI). So, if you make an entire community have an IP restriction, then only those IPs will have that "READ" permission. At this time, there's not a way to apply that READ permission differently for top-level communities than for their sub-communities/collections/items. "READ" always gives the permissions to see the object in DSpace 7.
The only way (that I know of) to achieve the behavior you suggest in DSpace 7 would be to only apply the READ restrictions to the sub-communities/collections/items, and leave the Communities themselves as READ Anonymous. However, that would result in empty looking Communities (to anonymous users), but once you login you'd see their sub-communities/collections/items.
Simply put, we don't have a way to display *only metadata* for restricted Communities/Collections at this time. Doing so would let users without READ permissions see the entire "hierarchy" (as you'd be able to read the basic metadata about all restricted Communities & Collections). So, in DSpace 7, we had to make the definition more strict: if you don't have READ, then the object is "hidden" to you.
Tim