Add a property containing all book ancestors

Yes, you are correct, at least I don't know of a way to currently do that. Also, this part is implemented in the Entity API, so any changes (or custom hooking) would have to be done there.
If you want to go the custom route, just adding a "child" property to nodes via hook_entity_property_info_alter() should work.

You could add this to the indexing logic when indexing books as custom
code, or when identifying if the entity is a book. Since book is a D7
core module you should support it right? ;-)

Some quick thoughts on how :

$more_parents = TRUE;
while($more_parents) {
  if(isset($node->book) && !empty($node->book['plid'])) {
      $parent = book_link_load($node->book['plid']);
      $pid = $parent['nid'];
      // Create the text structure here...
  }
  else {
    $more_parents = FALSE;
  }
}

Here is the implementation of the property, adding a list of all book ancestors.
This will then be available in Search API views displaying nodes as "Indexed node: Book ancestors", where you can just display them as a concatenation of labels.

This one should work, also updating the tests.

(Couldn't test myself, as running a test takes more than ten minutes, apparently, on this laptop.)

Well, once the automated tests pass it would of course be great if you could verify that the new functionality is working correctly.

1. +++ b/modules/book.info.inc
   @@ -20,4 +20,11 @@ function entity_metadata_book_entity_property_info_alter(&$info) {
   -}
   \ No newline at end of file
   

   files should end in a single new line.

2. +++ b/modules/callbacks.inc
   @@ -23,7 +23,22 @@ function entity_metadata_book_get_properties($node, array $options, $name, $enti
   +      debug($node->book);
   

   debug statement

3. +++ b/modules/callbacks.inc
   @@ -23,7 +23,22 @@ function entity_metadata_book_get_properties($node, array $options, $name, $enti
   +        $link = book_link_load($node->book['plid']);
   +        debug($link);
   

   debug statement.

4. +++ b/modules/callbacks.inc
   @@ -23,7 +23,22 @@ function entity_metadata_book_get_properties($node, array $options, $name, $enti
   +        array_unshift($ancestors, $link['nid']);
   +        $node = node_load($link['nid']);
   

   are you sure that you need to load the nodes? Shouldn't we be able to return just an array of IDs and the wrappers will take care of loading if needed?

5. +++ b/modules/callbacks.inc
   @@ -23,7 +23,22 @@ function entity_metadata_book_get_properties($node, array $options, $name, $enti
   +        debug($node->book);
   

   here too.

Oops! Sorry about the debug statements (it was really hard to find out what the hell was going on), and thanks to Bojhan for fixing them!

files should end in a single new line.

I know – that's why I added one in my patch. :P
Attached is the exact same patch as in #15, but with that newline re-added.

are you sure that you need to load the nodes? Shouldn't we be able to return just an array of IDs and the wrappers will take care of loading if needed?

We do return just an array of NIDs. However, we need to load the node to get it's book information.

+++ b/modules/book.info.inc
@@ -20,4 +20,11 @@ function entity_metadata_book_entity_property_info_alter(&$info) {
+    'description' => t("If part of a book, a list of all ancestors in the book hierarchy."),

We should clarify somewhere what book ancestors are, i.e. all book pages up in the book hierarchy, or so? I cannot think of more precise name instead of "book ancestors" but at least the description should me tell that.

+++ b/modules/callbacks.inc
@@ -23,7 +23,19 @@ function entity_metadata_book_get_properties($node, array $options, $name, $enti
+      while (!empty($node->book['plid'])) {
+        $link = book_link_load($node->book['plid']);
+        array_unshift($ancestors, $link['nid']);
+        $node = node_load($link['nid']);

Is there no more efficient way to do that? Looks like it will become slow if used for multiple nodes...

Else, patch looks good to me.

I'm not sure about book vs book page. Is "book" and "book page" the same, or does "book" just refer to the root of a book?

Else, the suggestion sounds good to me.

We should clarify somewhere what book ancestors are, i.e. all book pages up in the book hierarchy, or so? I cannot think of more precise name instead of "book ancestors" but at least the description should me tell that.

The description now reads as follows:

If part of a book, a list of all book pages upwards in the book hierarchy.

Is there no more efficient way to do that? Looks like it will become slow if used for multiple nodes...

Hm, yes, I guess so …
There's no "clean" way (i.e., using the API) of doing it, I think, but we could of course use the database tables directly, from {menu_links}'s p* columns we should be able to read the whole hierarchy in one go. Then one query to look up the associated NIDs from {book} and we'd be done.
If such lower-level operations are OK, we could also use that.

If such lower-level operations are OK, we could also use that.

If necessary, yeah. Let's see whether this becomes problematic and improve it if so.

Committed, thanks.