Sorry, I think I must be misunderstanding your description, as I'm unable to reproduce it (at least on a Mac running OS X 10.8.3). I just placed a popover on a layout, slightly above a tab panel control, and in the "Popover Setup" HUD I set the popover options to "appear [downward, i.e., overlapping the tab panel control] when possible." Result: the popover opens just fine and overlaps the tab panel control as expected. Am I misunderstanding your post?
Also, it's worth noting that popovers are brand new to the current version of FMP, so, if there were to be a bug related to their display identified and reproduced by the developer community, it would remain still present at least until a v-rev comes out. (Mind you, I may have missed previous community/forum discussion of this exact issue, in which case, ignore this post. There is a behavioral constraint re popovers not expanding over top of a web viewer that was described by seedcode, over here, although whether or not that one constitutes a bug is probably open to interpretation.)
Popovers don't overlap interactive container fields on OS X 10.9.x either. But their panels are scrollable when this occurs.
Thanks, jml. I wasn't aware of that one. The "interactive" part seems to be the common thread btwn your observation and John's observation re web viewers. That is, a popover won't display over a web viewer object that displays web data, but will open just fine over a blank (i.e., no data or url) web viewer.
("Blank web viewer! What the…?" ANS: I can't remember where I first learned this trick, years ago, but I like to use a blank web viewer to intercept layout background clicks, and thus suppress either automatic commits or a dialog asking if the user is ready to save changes. Makes forms behave more like those in standard applications. Sorry, a bit off topic, I know.)
Yeah sorry forgot to mention that the tab object contained a container object that held an image!