@ruebot In this case, I believe renaming the variables is a bug fix. 

If you search your own Islandora installation, you'll see that "islandora_book_gs" never gets defined by any of the Islandora modules. It never gets added to the Drupal *variable* database table, which is where the function `variable_get` always looks for it. This is the only module that refers to  "islandora_book_gs" -- yet it never defines it. It's obviously supposed to be the path to GhostScript.

If you look at the file `islandora_paged_content.install`, the path to GhostScript *does* get defined and saved in the *variable* table -- as "islandora_paged_content_gs". I believe "islandora_book_gs" is an old, outdated variable name. This makes sense, since books are no longer the only paged content in Islandora -- newspapers rely on this module, too. "Book" was removed from the variable name and it was given a more generic moniker:  "islandora_paged_content_gs". However, a few references to "islandora_book_gs" seem to have been missed along the way, which is what my patch is trying to correct. 

Why hasn't anyone noticed this problem before? Because the code `$gs = variable_get('islandora_book_gs', '/usr/bin/gs');` has a built-in backup plan: if it can't find a variable named "islandora_book_gs," it just uses the value "/usr/bin/gs" instead. If *NIX users are installing Ghostscript at that location, then they'd have no idea that again and again, the module is unable to find "islandora_book_gs." Windows users will never install Ghostscript at that location, which is why I noticed the problem. 

I wasn't able to create a book PDF until I corrected the variable name (the "Create PDF" button was grayed out and unclickable). Now I can.