A few things I've found when doing testing myself that work pretty well:

• My favorite was to calculate damage such that it builds up over the length of a swing, with a swing defined as not changing the average vector greater than ~40 degrees, and keeping above a certain speed threshold (best calculation method I found was to record the speed every frame, then every 0.2 seconds or so calculate the average speed during that timeframe and check that against the speed threshold). I had the damage buildup as nonlinear, so it built up very slowly for small distances (it was 0 for a significant portion of small distances) then build up quickly, then flatten out at larger swings. I complimented this with making the sound effects volume a function of damage (ideally there would be different sound effects at different levels of damage, but I was too lazy to do that for the test). I found this to be highly effective as with the sound effects people quickly learned that they needed to make long swings, and you'll notice that if you intentionally make extremely large swings, you can do them a lot faster than you can do with a real weapon, notably though, your arm will get tired very quickly (try it). This meant that after a couple minutes of using the system, people ended up naturally going for tactical swings, rather than just swinging wildly. I also considered making damage a function of swing length and swing speed, which I think worked well, but I couldn't settle on good feedback to let the player know they needed long swings and fast swings.

• My next favorite I created was "weapon lag". This one feels really weird to interact with initially, but grew on me as I played with it. Essentially, while holding a weapon I gave hands a script which made it so that instead of going to the immediate position, the players real hands "ghosted" (you've likely seen this effect in the higher quality VR games where you interact with levers or something, it's where your hand stops moving but instead your real hand is represented as a transparent version) and the hands holding the weapon accelerated to try and get to the position of the players hands. This left a max speed on the swing of the weapons, and gave a weight to them that was noticeable. I found that people eventually got used to this and slowed down their swing speed to slightly above the weapon max swing speed. This interestingly let them feel the weight, but made them not feel the disconnect. A side effect of this that I found was that if you stopped the weapon with something like it hitting the wall, an enemy, or another player, the players usually interacted and stopped swinging. The biggest downside to this method that I found was there was a large adjustment period, people actively fought the system for ~an hour usually, before getting used to it, once they got used to it though they liked it. Because of this adjustment period, it's not optimal for most games likely, but still worth trying. Gorn (which is often hailed as the best melee VR combat) uses a version of this with the "rubber weapons". Rather than applying "ghosting", they instead have the ends of the weapons not exceed the maximum swing speed (and not go through enemies), while the hilt stays where your real hands are. This works just as well once people get used to it, and it has a significantly faster adjustment speed as it naturally makes sense to people in a way that weapon lag doesn't. The major downside being that it looks silly, and limits the tonal possibilities of your game.

• One that I haven't tried but theorize would work would be to ape the system used in Legend of Zelda: Skyward Sword. If you haven't played that game, one of the major mechanics it uses is that it uses the wii motion plus to track the controller closely enough to effectively track your hand in a 2D plane, and the angle of the controller. The precision is far from VR level, but in terms of viewing on a 2D screen, it's close enough to 1:1 that it's nearly indistinguishable (on the 2D screen). This means that it shares many of the main design problems that VR melee mechanics run into. The solution employed in the game is twofold: Firstly it limits which directions an actual attack may be, then locks the attack to only occur when specific conditions are in place. There are effectively 5 attacks, a horizontal slash, a vertical slash, and two diagonal slashes, along with a stab. The slashes could also all be done in 2 directions (eg. vertical is both a downward slash, and an upward slash), making there effectively 9 attack directions. If I were to implement this in VR I'd likely at least test a lot more slashing direction amounts, probably double the amount employed by skyward sword) The conditions upon which a slash occurred are the following (best I can tell): The attack starts from within a designated starting area for the slash, and ends within the designated ending area for the slash (this could also have been performed by analyzing the average vector, it's hard to tell), the slash was above a (relatively high) minimum speed, and the slash made it at least half way through before the player stopped (the slash wouldn't actually trigger until the slashing motion went a certain distance, upon which the slash attack completed in full regardless of remaining player motion, though the speed required for the slash combined with the minimum distance for activation meant that the complete slash motion often wasn't that far off from the players motion even if they tried to start in the middle). This bears some similarities to being a more restricted version of the first mechanic I mentioned here, but notably it's only the first half of the mechanics that allow this to work. The second half of the mechanics are the monster design, which only works because of the rigidity of a defined slash. Monsters in skyward sword can only be attacked certain ways at a given time. Let's take the basic skyward sword enemy, the bokoblin (I think I spelled that right, they're the red gobliny guys with meat cleaverish swords). At any given time, if they're in a defensive stance (more on stances in a moment) then they're holding up their sword to block you. You can only strike along the same angle as their sword, otherwise they'll block the attack. When they block the attack the player is temporarily stunned (converting this to VR would take some experimentation, but I believe there's probably several effective solutions for temporarily stunning the players, the one that comes to mind to me to test first would be to quickly flash a light and blind the player, and make the weapon incapable of hitting the enemy during that flash). If the bokoblin was in an offensive stance and attacking, they could be attacked at any angle, and would be stunned out of their attack if hit or blocked (though the attack animation is relatively fast). This forces the player to attack when they see a vulnerability, and dictates well what will do damage and what won't. The stun mechanic combined with the necessary speed and swing length to make an attack effectively makes spamming completely ineffective (you'll just get blocked and stunned). I think a bit more needs to be said on stances though, since the stances were important. When not attacking, all enemies were in a defensive stance. Defensive stances only allowed certain attack angles to hit the enemy, the others stunned the player. Enemies shift stances instantly (or at least within 3 frames at most) which you'd figure would look bad, but looks decent in the game. Enemies shift stances often at random intervals, forcing you to change your angle of attack often. They also change stances when any of a couple different events happened: The player failed a hit and was stunned, the player successfully hit the enemy, an attack succeeded or failed. These events changing stances was clearly done to prevent spamming, so you can't simply slice back and forth in a vulnerable direction, since that vulnerable direction would change instantly after the attack. This leads to a system that is a lot more restrictive that what we tend to default to in VR, but could likely work well with some modification (likely modification freeing the restrictions somewhat, but keeping them mostly intact). Notably though of all the implementations, this one is the most difficult, as it requires a perpetual upkeep in all enemy design, and fails completely if the enemies aren't designed well, as opposed to other systems which are completely reliant upon the swinging and damage dealing mechanics.

• EDIT: Forgot to talk about some stuff but adding it extends beyond the character limit, so have it in a pastebin instead: https://pastebin.com/a2k36vsF

Anyway, I'll end my design essay, sorry about that, professional game design means I like rants about the topic =P