Demonstration: https://i.imgur.com/n6mGrvH.mp4

Plugin:

package spigottest;

import org.bukkit.event.EventHandler;
import org.bukkit.event.Listener;
import org.bukkit.event.player.PlayerChatEvent;
import org.bukkit.plugin.java.JavaPlugin;

@SuppressWarnings("deprecation")
public class Test extends JavaPlugin implements Listener {
	
	@Override
	public void onEnable() {
		getServer().getPluginManager().registerEvents(this, this);
	}
	
	@EventHandler
	public void onPlayerChat(PlayerChatEvent event) {
		event.getPlayer().setPlayerProfile(event.getPlayer().getPlayerProfile());
	}
	
}

Via...

• Version 3.2.0
• Backwards 3.2.0
• Rewind 1.5.2

Server is Paper 1.16.3 Build 204

I am pretty sure this is a wontfix. This happens due to how 1.16 handles dimension changes, Via can't really identify what the server is trying to do if you do this. I am not 100% on the code behind this but I'll get back here once I've analysed it.

Here is what happens in on the 1.16 server:

• Send remove entity packet
• Send add entity packet
• Send respawn packet to client to the dimension the client is in.
• Send location packet to the client.

Unfortunately in < 1.16 the logic for this is different. This is something that Via* won't fix. Via is made to not interfere with the server, and it would need to in this case.
That bug subject to an extra Via patch plugin much like ViaRewind-LegacySupport if anything else.

You work around this issue by teleporting the player somewhere sufficiently far away and back.

Unfortunately in < 1.16 the logic for this is different. This is something that Via* won't fix.

Why not? What is the difference between the packet logic? How would translating the packets "interfere with the server"?

That bug subject to an extra Via patch plugin much like ViaRewind-LegacySupport if anything else

Should I make an issue to a different repository?

@nathanfranke no difference in packet-logic but in the game mechanics.
In < 1.16 you'd get a respawn and the server would resend the chunks around you.
In 1.16 that is no longer necessary because the client doesn't clear chunk data if its sent to the dimension its already in on a respawn packet. Therefore the server doesn't resend that data.

The problem then becomes- How is Via* supposed to know you're trying to re-load the client and area? Via certainly doesn't cache the chunks to resend them if this happens, that would be absurd.

Via also can't intercept any event that may happen to detect this on the server when you do this.
This is by design. Via is designed to only translate packets so we can't expect to always know what the server is doing. (For example if Via is installed on a proxy like BungeeCord instead of a server).

This then becomes subject to another plugin to fix and that plugin doesn't exist (yet).
I imagine ProtocolSupport has a way to work around this because it deeply integrates with the server it runs on

Do you happen to know if it's possible to force the server to always re-send the chunks?

You could teleport the player somewhere else and back for it to resend data.

It's not just about chunks tho. You have other world state you need to replay. Replaying entities state is a task of it's own, because you need all the meta, status, velocity, position etc.etc. Just calculating current entity position and velocity based on position and velocity in the past for each entity type will take a shitload of time to implement. And then you have to do that also for entity status, particles, world events, sound events, etc, etc. Not worth doing all of that for same world dimension switch, which is only useful for self skin refresh.

If you really want to do dim switch, teleport player to other world and back, that will surely force the server to resend the whole world state.