Ben

...and when I get around to automatic guide creation - I'll look at Phi, and sequences.

You know phi is already available to use in expressions?
 
Try putting "h * phi" in the width entry on the Transform panel.
 
It'll work in any other entry field, so potentially already useful with Shapes, etc.

@Paolo
 
It was a recent(ish) change, but should be in 1.5.2 Beta 3.
 
If you don't name your Artboard Slice, it should track the Artboard name.  If you have named the Artboard slice, it will keep the name you gave it even if you rename the Artboard.  You can reset the Slice name by selecting the name, deleting all the text and hitting return.  The Slice will then revert back to the tracking Artboard name.
 
This only applies to Artboard slices.  All other slices will need to be named (and will revert to "SliceX" if you delete the name).
 
I'll look at adding a context menu command for collapsing all Layers in the tree.

Since this subject comes up often I am writing a definitive statement.
Fireworks (layered) PNG files
There is no such thing as "layered PNG".  The PNG standard does not define a way to store layers, and only deals with flattened images.
Fireworks saves out additional layer data to PNG files in a proprietary format using a private tag. A definition for this proprietary data has never been made public.  A PNG saved by Fireworks can still be used as a flattened image by any application that can handle PNG files.  These applications will handle the standard data and ignore the proprietary Fireworks data.
Affinity handles standard PNG files.  But, it cannot import or export the layer data using the Fireworks method.
There is no expectation that we will ever be able to handle Fireworks layer data in PNG files.
We acknowledge that being able to support Fireworks PNG files would be of great benefit to users of Affinity.  If a public definition of the data format becomes available, we will be able to address the issue.
 
Layered TIFF files
There is no such thing as "layered TIFF".  The TIFF standard only handles flattened images as part of the publicly described tags.
TIFF does allow for companies to register additional tags for their own use. Adobe registered two private TIFF tags that enable them to embed layer data in a TIFF.  These tags are an extension and are not part of the central TIFF standard.  These tags are used to embed PSD layer data into a TIFF, in addition to the standard flattened image.
Since Affinity has a PSD importer, we are able to import the layer data from a TIFF if it has these tags.  However, since this is handled by our PSD importer it is subject to the same limitations as importing a standard PSD into Affinity.  We make clear that while we aim to provide the best third party support for PSD, we can never replicate 100% the way Photoshop handles and displays a PSD file.  Photoshop has its own approach to applying alpha/transparency, vector masks and vector strokes, layer effects and gradients.  This means that while we can offer importing of editable elements of a PSD file, the result will not be a one-to-one pixel reproduction of what you see in Photoshop.
We have registered our own TIFF tags for embedding Affinity layer data in a TIFF, in similar fashion to PSD layer data. This is intended for use with DAMs that use TIFF as their interchange format.  When saving a TIFF file, if your document has multiple layers you will be given the option of including Affinity layer data.  This will preserve the editable elements of a multi-layer document.  This obviously comes at a cost of increased file size.  Our TIFF tags will use our proprietary data format and as such can only be used by Affinity applications.
At this time we have no plans to save TIFF files with the PSD format layer data.  PSD layer data held in a TIFF file will be imported and converted to the Affinity format.

ok - this can already be done, another way.
 
Start with a straight line that intersects the point you want to snap to.  Using the Node tool, create a new point on the straight line.  Then with snapping on, hold Shift and drag the point to the intersection.  It will constrain to the line, and snap to the intersection point.  You may need to select the other object, or have it as a snapping candidate for this to work.
 

 
If you already have a point that needs to snap to this intersection, delete it first, then recreate it on the straight line.
 
I'm reluctant to add snapping to put a point inline between two other adjacent points, because for the majority of cases you'd never want this - it would create a redundant point in your curve.
Also, to predetermine extra projections between non-adjacent nodes (i.e., to project an intersection between nodes 1 and 3), would add more complication to the snapping engine, not in terms of performance but possibly in terms of usability.
 
It may be that the Snapping Projections feature will cater for this.  This was a feature that was prototyped a while ago, but was held back until we were happy that it worked to our standards.

One can change the dpi without resampling. It's just an information field that can, but doesn't have to be, used in calculations.

Well, guess I am not done.
 
I use print establishments around the world--and have since 1989--I have yet to have a print establishment specify in PPI. Whether the information communicated was via a fax, mailed packet, email, or on their web site, the image information was always communicated as DPI.
 
I occasionally do business through some large print establishments. Some don't even have web sites per se. They go through brokers. But one of the large ones does have a web site. R.R. Donnelly. To this day they specify PDF/X-1a files and "Images must be SWOP (CMYK or Grayscale), TIFF or EPS between 200 and 400 dpi."
  Just saying that while I do (and have) agreed with the terminology swap you and others have proposed, the slight/subtle arrogance and/or put-downs (whether intentional or not--it's how some of the statements you have made have come across to me) will not achieve your desired goal.   In fact, at this point (or well past it), you have made your case. Serif have responded. If it is ever going to happen it will in the future but certainly not now.   Best regards, Mike

After spending countless hours reading into the differences between DPI and PPI I have discovered that many of us have been using PPI for years and simply never knew it. If like me and after investigating further you have now found yourself with PPI you may be entitled to compensation. As long as you have used PPI within the past 6 years you are still entitled to reclaim its never too late. 
 
If anyone would like any further support with PPI I have found the below guide to help you understand it better and make your claim.
http://www.ppiclaimsandadvice.com
 
C

Maybe... but I'm not saying it's necessarily right as it is now.  Your example shows that we may need to think a little more about how it works.

Where did you see the developers promise that Affinity would release a DAM app in 2016? They may have said at some point that they were targeting 2016 for a beta of Affinity Publisher, but that isn't a DAM.

Yeah ok... let's leave aching anatomy out of it. ;)

I am using the Windows beta.
 
Try this. Select both nodes by dragging the selection marquee around them with the node tool. Now hold the shift key and select the top node. Press delete. that should delete just the bottom node.

I'll look at this today....

I think I know what's going on.  We now add items to snapping candidates on selection.  So, if you select six objects, it'll clear out all the older ones from the candidate list.  This was a change we decided upon to help people more easily chose what goes into the candidate list.  I was unsure whether the candidates should be added when you select, or deselect.  Currently it's when they are added to the selection.
 
If you turn on the show snapping candidates option - you'll see when it happens.
 
You can still hover over the things you want to make a candidate while dragging your selection.  So - make your selection first, start dragging the selection, then hover over the thing you want to snap to.
 
For the example you gave, you could consider using the "Immediate layers" candidate mode instead.  You'd then not have to worry about picking candidates.

I'll look at this today....

That's already on my list for 1.6.

Having a general setting wouldn't work for everyone though.  Sometimes you might work with a small raster image, other times you might work on a large vector image.  So, a single grid setting won't work for all cases, not to mention the other grid styles we offer (such as isometric and triangular).  The automatic grid tries to provide a default grid before you've set one up specifically for the needs of that document.
 
I can see a possibility of assigning a grid preset to document presets, when we have the facility.

Would this be alleviated if we added Grid presets?

That's already on my list for 1.6.

I'll look at this today....

Layout grids?  You mean for web design, etc?
 
I plan to add as many wonderful grid and guide related things as we can think of, and as time allows.   ;)
1.6 will have some guide improvements.  I have a number of things on my to do list related to this.
 
Naturally, whatever we do, we'll want to push the boundaries a little.

Would this be alleviated if we added Grid presets?

I'll look at this today....

I'll look at this today....

Having a general setting wouldn't work for everyone though.  Sometimes you might work with a small raster image, other times you might work on a large vector image.  So, a single grid setting won't work for all cases, not to mention the other grid styles we offer (such as isometric and triangular).  The automatic grid tries to provide a default grid before you've set one up specifically for the needs of that document.
 
I can see a possibility of assigning a grid preset to document presets, when we have the facility.