That's an interesting question.
You mention you're trying to simplify the system. I've never thought needed layouts would make a system more complex.
The Virtual list technique is one way to get a report of sorts into a popover. There's many many great blog posts about it. Here's mine Using the Virtual List Technique - Part 1 - Soliant Consulting
You don't have a complex system, in my opinion, when you have many layouts. If you have unused layouts or unused Table Occurences, etc, you might have a complex system. But layouts themselves are not complex. In fact, the Report layout is designed for a report and the wizard you go through to create it does everything for you.
Popovers are good for viewing additional data such as more related record info. THey're also good as an editing interface: keeping the main layout free from data entry and putting fields into a popover. They're also good for creating new records and such.
And as I said before popovers could be used to show basic summaries of data through a portal or virtual list technique.
You asked about putting a tab in a popover. YOu can do that, I believe. I tend to use the slide panels now, but they're almost the same.
Floating windows are also good ideas.
Popovers, for more info, are context dependent. You have to show related records or data from the current record on there in the normal case. Even the virtual list technique most often uses a portal.
You may find trying to do reports in a popup more trouble than it's worth. Using virtual lists will be a given along with ExecuteSQL use. You'll lose the ease of creating summary reports with break fields and totals. You'll end up doing a lot more data parsing vs. a search and sort. Layouts are not evil, don't not fear them.
By Report I guess you mean a layout in FileMaker. You can always create a PDF and show the PDF as interactive PDF in your PDF.
When opening up your Popover, have a trigger creating the PDF and storing it in your Container field and then user will see your report in the Popover
I'll check out the Virtual List, but, also, I will take a deep breath and come to terms that having a few layouts is not the end of the world. :-)
My recommendation is to have as many layouts as you need.
Here are some types of layouts developers typically have:
1. Data Entry layouts.
2. Read only layouts
--- These two layout groups might have duplicate layouts with just the data entry option toggled.
3. Developer layouts
---- these are dev-only layouts that are unformatted / unpretty that are used to view and manipulate data. Often they're in the table format. These are not accessed through any scripting or button or navigation; they're simply there for the developer to get a behind-the-pretty view of the data.
4, Blank layouts
---- these are layouts that are based on the form view that have no fields on them. Again, they're unpretty. Typically these are the layouts you go to in a script to create a new record and/or populate a bunch of fields. I believe it is faster to create records on a layout with no fields. That's what we typically do. I heard somewhere, though, that that fact isn't true. Not sure.
5. Other layouts.
---- Other layouts are there for various purposes.
Many of these layouts are based on the same TO. That is okay. You need different types of layouts to do different things.
The moral of the story: Create the layouts you need. Keep them organized in certain folders (I use a folder called "Dev" for my dev layouts; I name all my blank layouts with the TO name and then "_Blank").