See attached for what I'm doing and seeing.

Good idea. Tomorrow...

Ah, yes. I can get there.

To sum it up, if you create a folder that has only one or more views in it, and no other content, and you enter that folder, the Review mode sends you into the trackless gray wilderness. Happily, you can ESC out of it, even though there are no visible controls.

If there's anything else in there, like a single JPG, Review mode shows you that JPG, with no "previous" or "next," as it should.

You've probably created those views in the "Views" folder, which only contains views. As views shouldn't traverse other views, you get blank results. Views are sensitive to the current folder they were created in, so if you want them to traverse the root, create them in the root, then move them to where you want them.

Quick test using obj.isIncluded() and obj.isFolder()
The first finds all objects that aren't folders, the second finds nothing. But no smoke and flames!

rc9 now available as a beta update. This version fixes the duplicates that appeared within views.

Geek warning below:
With this version, I've also updated the power of jAlbum's iterator API. As you may know there is a AlbumObject.getDescendants() method call that saves you from needing recursive calls like this if you wish to iterate a folder tree:

Old sample code (flatten transformer):

    public AlbumObject transform(AlbumObject tree, VirtualFolder newRoot) {
        List<AlbumObject> children = tree.getChildren();
        if (children != null) {
            for (AlbumObject ao : children) {
                if (!ao.isView()) {
                    if (ao.isFolder()) {
                        if (!ao.isHidden() && ao.isIncluded()) {
                            transform(ao, newRoot);
                        }
                    } else {
                        newRoot.addFileOf(ao);
                    }
                }
            }
        }
        return newRoot;
    }

Note the checks for !isView() in order to avoid traversing into sub folders.
BUT, recursive code is always a bit challenging to write. The very least, you have to introduce a method call. That's why I added the getDescendants() call. An optimistic rewrite of the code above using getDescendants() would look like this:

        tree.getDescendants()
                .stream()
                .filter(ao -> !ao.isView())
                .filter(ao -> !ao.isFolder())
                .forEach(ao -> newRoot.addFileOf(ao));
        return newRoot;

Much more readable, and shorter, but I introduced a bug now: The filter is applied to each and every AlbumObject of the tree, so when I filter out a View or a Folder, their children will still be included. I needed a way to apply filters BEFORE sub folder iteration, and now you can do that, like this:

        tree.getDescendants()
                .filter(ao -> !ao.isView())
                .stream()
                .filter(ao -> !ao.isFolder())
                .forEach(ao -> newRoot.addFileOf(ao));
        return newRoot;

Not in my test. Create a project with a few JPG's. Now create a folder, and put some internally-linked objects into it. Now create a view, like alphabetical. The view contains duplicates of objects that are in the root, and internally-linked objects from the folder of links.