ralf
I also agree that the "delete hole" problem should be fixed, no matter if and when ripple editing will provide an alternative for this feature.
After all, this is a regression bug (something that worked before), so to fix it, one only has to compare the working code and the no longer working code, and find the difference. (Sure, may be more complex depending on what was changed and if it was a side effect of some other change, but still regression bugs tend to be rather easy to fix.)
This is somewhat irrelevant as Software often has so many dependencies that you just can't make that assumption. Also, If the Software team is working on a future implementation of something that fixes other bugs in a previous implementation, they will weigh the resources needed and if the issue is complicated to fix (which this must be as I'm sure take lane and comping changes have made this area very complex) often just wait to fix it in a future release under the new way. This is common but only if the new implementation will be released in a reasonable time frame. User report bugs, and the delete hole is a serious bug at times, needs to be fixed in some reasonable timeframe somehow.
WORKAROUND to the delete hole of tracks with no data. Knowing this is an issue, you need to make sure the clips in the delete range all have data. You can temporarily slip edit the clips into the space, you can bounce to clips and include clips on both sides of the space, or create silient clip to take up the space. I tend to bound the clips if the space is large and encompasses many tracks or slip edit if the space is small.