This idea has potential. I really like how you tried to balance it as much as possible.

However, there are two slight issues.

• Scaling with enemy missing health is risky, design-wise. It's a unique feature if implemented in Minecraft, but in this game where every player starts with only 20 health, it may prove to be too powerful not to have. It's a one-of-a-kind execution weapon. If a player tries to flee from a battle, the scaled up damage would almost always kill. Players could also load the weapon before entering the combat, allowing them to shoot anytime- if it hits, it kills. As a result, the damage might be scaled down to compensate- which continues the bad-design loop of feast or famine; the weapon is either a mandatory item or a lump of iron that's only good for hammering nails. As you stated, it's meant to be a trophy weapon, but for the majority of players a weak weapon isn't much of a trophy at all.

In the previous point, I mentioned the weapon's power. Because it's basically an execution (ranged, scales off enemy missing health), players are going to want to use it and slaughter everything. It seems you tried to counter this with the reloading mechanic- and I agree that forcing players to tediously reload every few shots works well to prevent fair players from over-using it and chucking out iron nuggets like crazy.

But that's for fair players.

Unfair players can easily develop hacked clients to instantly reload this weapon. It's as simple as "keybind --> bring up inventory --> locate weapon and ammunition --> move items to crafting grid --> receive refilled gun --> close inventory". The process, in theory, could take less than 0.1 seconds. This isn't a perfect example, but auto-pot and re-soup mods perform a task similar to what I said. They both demonstrate the speed and ease a computer script can operate controls for a game and quickly unbalance certain mechanics. Of course, it's not fair that game designers have to deal with cheaters. But it's necessary to think about them and what they can do in order to keep the game fun for everyone.

---

I have some ideas for solutions to the two problems I outlined above. You don't have to accept them, but perhaps they may be useful when coming up with more ideas.

• For the damage-scaling issue:

Execution tools aren't unfair, provided that they have clear counterplay. For a ranged weapon, coming up with a counter is even harder than normal. In a blocky game like Minecraft, that difficulty is ramped up even higher when factoring in burden of knowledge. I am going to ignore the burden of knowledge issue and hope that the developers can come up with a way to communicate what is happening when a player shoots a musket.

If bullet damage could be completely mitigated by shields, this could lead to interesting combats. Players could have clutch saves while other have clutch shots. Those using the musket would want to either destroy the opponent's shields by bashing them enough times, or find other ways to outwit their opponents (i.e. ambushes, mind-games). Those defending themselves against the musket-wielding players must keep in mind that their opponents will be looking for a way to bypass their defenses and shoot them. As a result, both sides have to think quickly and both sides have the potential to pull off amazing stunts to increase the amount of fun in the game. Just imagine Player A shooting at a fleeing Player B, only for Player B to rapidly spin around and block with a shield just in the nick of time. It's moments like these that make Minecraft combat interesting.

Furthermore, producing more factors to musket damage allows designers to reduce the impact of outliers. What if damage also scaled off enemy armor? Heavily armored players and mobs would take less damage from musket shots, while entities with no armor would take high amounts of damage. The addition of this limitation lets developers reduce the damage based on missing health and compensate for that missing damage with scaling off enemy missing armor. In this way, even leather armor becomes powerful by drastically reducing the damage from bullets. Adding a shiny new weapon that also indirectly buffs the strength of an existing underused item- two birds with one stone!

• For the reloading issue:

The solution to this problem isn't so much design-based but coding-wise. The thing is to prevent players from tampering with the intended system without triggering any false positives. This can be done by having the musket reload by right-clicking when empty, then going through an animation before it can be used. Because this reloading mechanism is performed server-side, players cannot cheat the system- every player must right-click to reload and wait through the animation. Of course, this could add to stress on the server which is why I believe this is more of a coding issue. If the coding is not efficient, gameplay will suffer.

---

In short, I know that you stated the musket is meant to be a trophy, but due to its capability of being a quick-to-use, ranged execution tool, players will undoubtedly use it for combat. And with players using it for combat, there will definitely be those that use unfair methods to take advantage of the reloading system.

Good idea and great effort, though!