Touying uses LogicalPage pdfpc metadata to identify which slide a speaker note goes to such that a note is associated with the correct slide, regardless of animation. However, these labels refer to the labels in the PDF specified by /PageLabels. Typst will export these only if page.numbering is set to a valid numbering pattern, i.e. arabic, roman, alphabetic (see page.rs).

Touying doesn't seem to ever set page.numbering to anything, which means that the labels are not exported. This, in turn, means that pdfpc (among many other readers) assumes the default labels of 1, 2, 3, ..., which, combined with the logical numbering assumed by touying will cause pdfpc to associate the notes to the incorrect slides once any animations are involved. (Here's a relevant upstream issue on the pdfpc repo)

I've patched touying locally to write the label when it encounters a Idx pdfpc metadata like so:

--- src/pdfpc.typ	2024-10-14 13:38:47.640696159 +0200
+++ src/pdfpc.typ	2024-10-18 09:44:21.940388007 +0200
@@ -23,8 +23,10 @@
     for item in slide {
       if item.t == "Idx" {
         page.idx = item.v
+        // NOTE: fix for lacking /PageLabels export of typst, resulting in incorrect page labels
+        page.label = str(item.v + 1)
       } else if item.t == "LogicalSlide" {
-        page.label = str(item.v)
+        // page.label = str(item.v)
       } else if item.t == "Overlay" {
         page.overlay = item.v
         page.forcedOverlay = item.v > 0

This would not work, if a user sets the numbering themselves, but I included it as a workaround for others who may need a fix. I believe, touying must retrieve page.numbering to set the correct labels when placing LogicalSlide and fallback to Idx + 1 where it is none, but I have no time to create a PR for this right now.

If this patch causes conflicts or other problems for you, I've applied this to 0.5.2 because I ran into a regression with 0.5.3, which I want to come back to next week.