Great questions! You're totally right that in lots of ordinary cases, this plugin provides machinery that doesn't fit, but that's not why I made the plugin. (Also, if you look at the development roadmap in the README, you'll see that I have plans to include more traditional path algorithms.) There are a few reasons I prioritized this niche case during development:

• Checking which rooms you've been, and in which order, etc. is something that's too broad and dependent on the game, and can usually be set up easily with a sensor collider and some bitflags. I wanted my path plugin to provide something that was more unique and provided something that would otherwise be too much a pain to implement yourself during development.
• It's fun! I'm a mathematician. I'm not really much of a game developer as it stands. I wanted to be able to record the homotopy type of a moving object. Now you can, too. If it's not useful to you, that's OK, but I think it can be!

There are also a few specific use cases I had in mind:

• Imagine you're developing a tricky logic puzzle in a game like Baba is You, and you want to make sure that your intended solution is the only solution. You could place puncture points in such a way that the player's path (up to homotopy) will record whether they took your intended route, instead of finding an unintended route or a bug which trivialized the level.
• Physics engine debugging. Here's an example: imagine you have a rope following the player, and that rope moves according to a physics engine, and you want to make sure it correctly wraps around some posts. To check this, you can record the path of the player and make sure that the rope's placement in the world, when treated as a path, is homotopic to the path the player takes.

However, there are use cases I can imagine outside of the context of debugging. You could utilize this plugin to introduce new mechanics into a game: 

• One classical example that comes to mind is the Mario 1 castles in worlds 7 and 8, where you have to navigate the platforms in the correct order to progress. The checks they do for that are extremely buggy, and the notion of having taken the "right path" wouldn't even be well-defined if you were able to backtrack to the left. A puzzle like this becomes a LOT cleaner to implement with this plugin, and I plan on including that as an example in the crate in the future.
• Let's go back to the rope example: let's say you've got a farming game, and you want the player to be able to build a rope fence. Maybe the game mechanic for doing so is to start with the rope in the player's hand, do a full loop around post A, do a full loop around post B, and then pull it taut (by, e.g., walking a little away from post B). That's a perfect micro use case for this plugin.

As for your point about the use of String: the word() method gives a representation of the loop as an element of the fundamental group π_1. The tools are already there to accomplish what you suggest, but I prioritized debugging over expanding the public API when making this.

Also, one minor point -- it's not homology, because the order of traversal does matter. H^1 is the abelianization of pi_1, so if it recorded the homology, going around A and then B would be the same as B then A.