I recently had to track down a problem with DateTimePatternGenerator where for certain locales and skeleton strings, I was getting unexpected results. In particular, the pattern you'd get back the skeleton "y" for en_GB@calendar=buddhist and en_GB@calendar=japanese was "y", missing the era field required by those calendars (en and en_US worked fine).
I believe the problem here is that inheritance is broken whenever there's an alias directive in the resource inheritance chain. If I put printf() statements in AvailableFormatsSink::put() to show which resources are being added to the pattern generator's lists, when my locale is en_GB@calendar=gregorian, I see the entire contents of calendar/gregorian/availableFormats from en_GB.txt in my output, followed by all of it from en_001.txt, en.txt, and root.txt, in that order. Same thing for en_GB@calendar=chinese. But if I try en_GB@calendar=buddhist or en_GB@calendar=japanese, all I see in my debugging output is the contents of calendar/generic/availableFormats from en_GB.txt-- the contents of calendar/generic/availableFormats from en_001.txt, en.txt, and root.txt are not present. en_GB doesn't have resources for calendar/buddhist or calendar/japanese-- in both cases, we fall all the way back to root.txt, which aliases availableFormats for both calendars over to calendar/generic. My hypothesis is that the "sideways fallback" to generic is somehow preventing any further "vertical fallback" to parent resource bundles from happening. I worked around this by adding the necessary patterns to en_GB/calendar/generic/availableLocales, but this really seems like a bug in either ResourceBundle or DateTimePatternGenerator.