fde101

When "Apply to Selection" is not checked, the color which is picked up is placed in the circle used by the color picker which is embedded in the Color panel, which you can click on to set it as the fill or stroke color (depending on which of the circles is selected there).  It is not directly selected as a stroke or fill color, possibly because doing so might have the side-effect of setting the fill or stroke color for whatever is selected?
Alternatively, you do not need to have a layer selected if the "Source" is set to "Global" in the context toolbar.  If you keep all layers deselected, then you can leave "Apply to Selection" checked and the color will be set by the tool without impacting the colors of the existing layers.

One thing to remember is that Photo *never* actually opens a JPEG.  It always works with its own custom document format.
When you "open" / import a JPEG image, it is being placed on a layer in an Affinity document.
When you "save" / "export" the document, you are exporting the Affinity document, not just the JPEG image.  Even if the image itself was not touched, you are not exporting the original JPEG, but the Affinity document which just happens to match its appearance.
Consequently, you are not "recompressing" the JPEG, but newly compressing the Affinity document which did not previously exist.

One problem you are going to face is that as soon as you export it to some vector format it will *always* be an approximation of some sort.  Sine and cosine waves are interchangeable with each other, but neither can be perfectly represented as a Bézier curve, and they cannot be coded into most vector graphics formats.
There is some discussion around this here: https://math.stackexchange.com/questions/4235124/getting-the-most-accurate-bezier-curve-that-plots-a-sine-wave
PostScript does have a few trig functions, including sine and cosine, so PDF might as well (I can't seem to figure out the right search terms to identify this), so it *might* be possible to code this into a PDF, but other vector formats (such as SVG) would only be able to contain approximations.

One problem you are going to face is that as soon as you export it to some vector format it will *always* be an approximation of some sort.  Sine and cosine waves are interchangeable with each other, but neither can be perfectly represented as a Bézier curve, and they cannot be coded into most vector graphics formats.
There is some discussion around this here: https://math.stackexchange.com/questions/4235124/getting-the-most-accurate-bezier-curve-that-plots-a-sine-wave
PostScript does have a few trig functions, including sine and cosine, so PDF might as well (I can't seem to figure out the right search terms to identify this), so it *might* be possible to code this into a PDF, but other vector formats (such as SVG) would only be able to contain approximations.

One thing to remember is that Photo *never* actually opens a JPEG.  It always works with its own custom document format.
When you "open" / import a JPEG image, it is being placed on a layer in an Affinity document.
When you "save" / "export" the document, you are exporting the Affinity document, not just the JPEG image.  Even if the image itself was not touched, you are not exporting the original JPEG, but the Affinity document which just happens to match its appearance.
Consequently, you are not "recompressing" the JPEG, but newly compressing the Affinity document which did not previously exist.

One thing to remember is that Photo *never* actually opens a JPEG.  It always works with its own custom document format.
When you "open" / import a JPEG image, it is being placed on a layer in an Affinity document.
When you "save" / "export" the document, you are exporting the Affinity document, not just the JPEG image.  Even if the image itself was not touched, you are not exporting the original JPEG, but the Affinity document which just happens to match its appearance.
Consequently, you are not "recompressing" the JPEG, but newly compressing the Affinity document which did not previously exist.

It does that.  All of the Affinity products do; this does not mean there is a leak.
If you had evidence that there was a leak, then it should be filed as a bug report.  This part of the forum is meant for feature requests.
 
Bug reports go here: https://forum.affinity.serif.com/index.php?/forum/71-bug-reporting/

The problem here is that the export persona is decidedly biased toward artboard-based documents, while Publisher is intended primarily toward page-based documents, with rather different requirements for export and publication.
The Photo persona in Publisher makes sense to allow manipulation of photos embedded within publications, and the Designer persona similarly to enhance the ability to work with vector artwork within publications, but while it is possible to work with artboard-based documents (as well as standalone photos) within these personas within Publisher, that does not seem to be the intended function of their inclusion.
Including the Photo and Designer personas within Publisher does not strike me as an inconsistency in these statements as their inclusion does well to support Publisher's primary function of supporting page-oriented print-focused document preparation, but the additional personas (Export, Tone Mapping, Liquify) do not really contribute toward this purpose, and so would be much more out of place within the product.

It probably will as Serif has consistently indicated over the years that they have no intention of merging the apps; examples:
 
 

Publisher does offer limited access to the Develop persona, but it is slightly hidden.  If you insert a RAW image, the context toolbar shows a "Develop Image" button that switches to the Develop persona for that image.
While Photo does allow access to the Develop persona for non-RAW images, it doesn't really make that much of a difference since just about everything that can be done in the Develop persona with a non-RAW image could be done just as well in the Photo persona.
What is really "missing" in Publisher mostly amounts to the Liquify, Tone Mapping and Export personas.
Personally I think that is fine - I would rather they add a Prepress persona to Publisher and a Tracing persona to Designer.

You do realize you can do stuff like that in the Finder too, right?
You can set up the search and save it, with the option to include the saved search in the sidebar.

Publisher does offer limited access to the Develop persona, but it is slightly hidden.  If you insert a RAW image, the context toolbar shows a "Develop Image" button that switches to the Develop persona for that image.
While Photo does allow access to the Develop persona for non-RAW images, it doesn't really make that much of a difference since just about everything that can be done in the Develop persona with a non-RAW image could be done just as well in the Photo persona.
What is really "missing" in Publisher mostly amounts to the Liquify, Tone Mapping and Export personas.
Personally I think that is fine - I would rather they add a Prepress persona to Publisher and a Tracing persona to Designer.

Is this a feature request (you want Serif to continue breaking things with every update), or is it a misplaced bug report in the wrong place on the forums?

I'm sorry to say that I think this is not a Good Idea™ because often you would want to see all stroke parameters laid out upfront, not buried under popover panels. Also, the Appearance functionality is a Designer exclusive, whereas the Stroke panel alone is just as important in Publisher for fine adjusting text outline attributes. Then, Color parameters have so many different variants that you would have to literally merge the whole Color panel into the Stroke panel.  Whenever you want to apply color to strokes, you always have the color panel flyout handy on the context toolbar. And lastly, I, for one, hope that the Stroke panel will eventually gain more functions. Those will need the currently free real estate.  

Serif has stated in the past that they were not happy with the results they were getting from tracing using the algorithms they had on hand and that when they introduce this into the Affinity suite they want to do it right and have something better than what they could achieve right now.  There were also hints that they intend to do this in a big way and implement it as an entirely new persona just for this task.
This was some time ago, however, so not clear what direction this may currently be taking - still, I would expect this will come in time, but they are waiting until they can do it in a way that they will be happy with, which I can certainly get behind.

Is this a feature request (you want Serif to continue breaking things with every update), or is it a misplaced bug report in the wrong place on the forums?

I believe the file format was designed to allow the file to be updated in place rather than replaced as a performance optimization.  Rather than writing everything each time you save, the application only needs to rewrite parts of the file that have changed.
If that is an accurate assessment, then a feature such as the one you describe would defeat that optimization and slow down the save process by forcing the application to write the entire file every time it gets saved, as Photo does now when doing PSD round-trips with DAM/raw processors such as Capture One, which takes quite noticeably longer than saving a native Affinity document does after the initial save.
This is not to say that it couldn't be done, or that it shouldn't be considered, but it is a factor to bear in mind that would likely be impacted by enabling a feature like this.

Is this a feature request (you want Serif to continue breaking things with every update), or is it a misplaced bug report in the wrong place on the forums?

You may be better off pushing the Wine project to improve their Windows emulation support in the areas that currently prevent the Windows version from working well via that mechanism.
You would *definitely* have been better off adding this to one of the existing threads on the topic rather than forking off yet another pointless duplicate one.

It actually stores and uses non-integer values behind the scenes, but rounds them for display.
Some values allow the rounding to be adjusted in Preferences/Settings, but I don't see one for percentage values (which would be nice to have added).  I believe that may have been requested before.

Not true if you have a pixel selection and there are no layers selected (though offhand I think the option should be disabled in that case - maybe making it even more confusing to users who are not aware of which selection it refers to?)
You could do something like "Selected Layer(s)" or "Layer Selection", possibly "Vector Selection" if you would rather go that route, but I agree that some way of more clearly denoting that this is not the pixel selection should be considered.

The Arm64EC thing is kind of interesting, but it is basically a transitional tool for developers to use to gradually provide native ARM64 ports as part of the development process, it is not how the "emulation" Windows provides work.
My comment was more that I don't think Serif is doing this at all - I don't think they are explicitly transitioning their apps to ARM for Windows (yet?) - so they are likely fully "emulated" at this point (in whatever sense Windows "emulates" x64 under ARM64 systems).

UI font size should really be controlled by the operating system rather than the application, but there actually is a "Large" option under the User Interface section of Preferences/Settings (at least on macOS; from what I have seen on the forums the Windows version is missing a few of the UI options that the macOS version offers).

The Arm64EC thing is kind of interesting, but it is basically a transitional tool for developers to use to gradually provide native ARM64 ports as part of the development process, it is not how the "emulation" Windows provides work.
My comment was more that I don't think Serif is doing this at all - I don't think they are explicitly transitioning their apps to ARM for Windows (yet?) - so they are likely fully "emulated" at this point (in whatever sense Windows "emulates" x64 under ARM64 systems).

No, it isn't.  It is not a bad additional option, but named tags would be preferable to color tags, particularly since there are already colors for layer layers which may lead to confusion between the layer colors and the color tags.  Named tags are not subject to color blindness or to having subtle shades making them difficult to differentiate.
 
Consider:

 
If you were not familiar with the program, would you know what the layer color was, and what the color tag was, based on seeing something like this in the layers panel?
 
If you could customize the color tags, users may eventually start doing things like what I did here with the layer colors (which are the ones to the left of the thumbnails for anyone who does not know):

 
You can only get so many colors in before you start resorting to things like that - not an issue with tags that have names instead.
 
The one downside of named tags is that they would be too big to reasonably fit in the layers panel, so you maybe would just need a generic tag icon to show that there are tags, and provide the names of those tags in a tooltip or similar.