tl;dr - the issue isn't with the current system, just the way you interact with it.
Great post. It really highlights some of the complexities of design decisions that go into creating a good UI.
I find that the current system is "close enough" in that the issues that I have with it are usually associated with other issues, not the system itself. For example, having my inventory full of "temporary blueprints" is solved by having a copy-paste system.
The main issue with the blueprint library is the ability for someone to find what they are after. The current view is probably the worst you could think of. The MOST important part of any blueprint stored in a library is it's name, not it's icon. How many times do you have to see a rail icon to realise that it's not important? If the view was changed from a thumbnail view to a list view (like MS Windows explorer's list/detailed view) you would find the usability would shoot right up. Couple that with a search box and you suddenly have a much more usable interface. It would also make it more clear that the UI does actually sort it by name and that it's name is important. It would also allow for much longer names. The current "limit" of 10-15 characters is just too small. By the time you put some type of "category prefix" on your blueprints, you can't see what the blueprint actually is! eg "rail outpost - Copper" shows ups as "rail outp..."
As for some of the changes outlined in the various options put forward:
I think that blueprints as-an-item are essential.
If you have a big blueprint library then it's easier for you to find what you're after than for someone else to find what you are trying to describe in chat.
(Kovarex solved this issue with his item-in-chat solution) I also use blueprints as-an-item to archive. In many of my long maps I have chests around all with the previous versions of builds. This way if I ever realise that a previous version could be used again, I have them.
As for a maximum slot limit: I would HATE it. I already have 6 "installations" to deal with multiple mod setups and I will be very unhappy if you guys go to all that trouble of implementing mod synchronisation to at the same time effectively limit me to only 5 books per setup.
If you just look at the list of issues you are dealing with and deal with each one individually, you will see that the issues aren't inherent to the current system but are just superficial issues with the way the user interacts with the current system.
1) Clicking the blueprint in the blueprint library means creating a blueprint:
Then don't create the blueprint? You could do one of two things. If you can now do drag & drop (It wasn't an option due to the libraries your using but with the rewrite it may be possible?), then make a blueprint by dragging and dropping it into your inventory and put it into the copy-paste buffer when clicked on (in the "active paste buffer" as if ctrl-v had been pressed and a selection made).
OR (my personal opinion)
the copy mechanism is the only way to make a blueprint. If you copy (either by clicking on a blueprint in your library OR by ctrl-copy->make selection) it makes a "temporary blueprint". This blueprint, when cleared gets destroyed. If instead of clearing it, you click on your inventory/quickbar THEN the in-game item is created. It also has the added benefit of having ctrl-v recall the last blueprint either copied from the map or copied from your blueprint library.
2) Blueprints getting out of date in the blueprint library.
This isn't the issue. This is actually 2 issues, so deal with them individually.
2a) Not being able to get access to blueprints in other games
Is this really an issue? I'm of the opinion of: I don't know. It doesn't bother me that much that I have to swap maps to get access to a blueprint that I "forgot" (or didn't realise that I would have to) put into my blueprint library.
2b) not knowing what blueprint is the most up-to-date.
Again I have to ask: Is this an issue? Are you making a dumbed-down game where every mechanic is easily understandable to its full extent? or are you trying to make the basic functionality more user-friendly? How about putting a created date timestamp then? Then new players could see if one blueprint is older than another. I personally have solved this by adding "version numbers" to my blueprints: I append v.xx to the end of my blueprints.
3) The standard way of putting new blueprint into the blueprint library just puts it at the end of the blueprint library
Umm, no it doesn't. It's sorted alphabetically. The issue is: If the developers don't understand this then it's an issue with the way that information is displayed/conveyed to the user!
4) Once new players open the possibility of making blueprints, it opens many things at the same time for them
Again, not quite right. You have blueprints & deconstruction planners right from the get-go. The issue is that it's a little button right up in the top of the screen, next to other (seemly informative only) buttons. Move the button NEXT TO THE QUICK BAR!!! (better option to follow).
5) Other UI annoyances such as exporting and importing blueprints through the obscure "Drop here to move blueprint" box.
Then do the same type of UI as the transfer between chests & user inventory? Or as you were/are looking at a "tab" system https://www.factorio.com/blog/post/fff-191
put the blueprint library as an extra tab (so accessed by F4).
Sorry, this ended up being much longer than anticipated.