Ben

Would this be alleviated if we added Grid presets?

Is there some reason you do not want to use the Square Star tool to make this shape?

Our Point is the conventional 1/72 inch.  So, I'm guessing we'd opt for the 1/6 inch Pica.
 
We've not had anyone ask for the other Point type.  Not sure how we'd go about that.  We use the "pt" suffix to denote anything in 1/72 Points, for both UI display and value input. The suffix could not identify both types of Point simultaneously, so it could only be an app-wide preference that "pt" represents one or the other if we were to ever support it.
 
If we are adding Pica, it won't be in the 1.5 release cycle.  I'll ask the other guys if we can look to add it for 1.6.

Our Point is the conventional 1/72 inch.  So, I'm guessing we'd opt for the 1/6 inch Pica.
 
We've not had anyone ask for the other Point type.  Not sure how we'd go about that.  We use the "pt" suffix to denote anything in 1/72 Points, for both UI display and value input. The suffix could not identify both types of Point simultaneously, so it could only be an app-wide preference that "pt" represents one or the other if we were to ever support it.
 
If we are adding Pica, it won't be in the 1.5 release cycle.  I'll ask the other guys if we can look to add it for 1.6.

I don't understand the problem.  The presets are initially expressed in the unit that they are historically measured in. When you pick a preset, the unit type will change to the type associated with that preset.  There is nothing stopping you picking a preset, then changing the unit to the one you intend to work in.  It will still work.  The physical size of the document will still be the same, but everything will be shown using the unit type you chose.
 
All the presets that use inches do so because their sizes are nice round numbers - they are based on inches after all.  I think most people get "4x6 in" rather than "152.4x101.6 mm". Much more readable in inches, and way more easy to understand the ratio of dimensions.
 
You can change the document units at any time in the Document Setup dialog.  Changing the unit type will only change the way the values are shown in the UI - the document will still be the same size, unless you change the DPI value or edit the page width or height.

@Balling
 
Actually - between all our teams members, we have a lot of experience in both print and software.
 
As I've pointed out - those who need to concern themselves with DPI or PPI already understand what both terms mean, and anyone who needs to convert that to real world print should also understand the implications and how to control the quality of the result.  If they don't, as I said, they probably don't get it full stop.
 
You need to appreciate that our software serves multiple disciplines, not just print, and some industries are more comfortable with one terminology or another.  We tailor our UI to suit the best overall case, and if there is enough weight to dictate we use one terminology over another, then it will get changed.
 
The argument has largely been about us using "DPI" instead or "PPI" in one place in our UI.  Fair enough - but you've not been fair to everyone else who has expressed their thoughts on the subject, believing that no one else has your understanding or experience.  Not so.

@Balling
 
At the end of the day DPI, PPI, or whatever you want to call it is just a number.  It doesn't change how many physical pixels you have in your document - though it will effect rasterisation of non-pixel content.  It is interpreted to have meaning depending only by the end use of whatever image you are producing.  Anyone who has to concern themselves with DPI (or PPI) will understand that it is completely separate to the physical media scale on which it is printed or displayed, or the sub-pitch of the ink dots that the hardware produces.  These people who you say get confused by DPI and PPI will no doubt still be confused whatever we call it... perhaps they are in the wrong job.

I like the variety of measurements. How boring would the world be if everything was standardized?

Alleluja!

@Balling
 
At the end of the day DPI, PPI, or whatever you want to call it is just a number.  It doesn't change how many physical pixels you have in your document - though it will effect rasterisation of non-pixel content.  It is interpreted to have meaning depending only by the end use of whatever image you are producing.  Anyone who has to concern themselves with DPI (or PPI) will understand that it is completely separate to the physical media scale on which it is printed or displayed, or the sub-pitch of the ink dots that the hardware produces.  These people who you say get confused by DPI and PPI will no doubt still be confused whatever we call it... perhaps they are in the wrong job.

It's because that is not the bounding box.  It's what we call the Base box. That is the box into which we project the shape, and the box you control to initially create the shape.
 
Some shapes are based on a circle, which we project into the Base box. So, the circle centre is always at the centre of the box, then the radius is projected to the top/bottom and left/right edges (which will form an ellipse if the box is not 1:1).
 
This method allows you to create uniform ratio shapes by stretching out a constrained 1:1 box.  If we did not base it on a circle, and filled the box with the shape, the shape would not be 1:1 ratio, and the centre point would jitter as you added or removed points.
 
For snapping and alignment purposes, we allow you to get the tight bounding box by pressing the . (full stop) button.

These things have already been thought about..... not saying much more right now.

On a Mac, & I assume on a PC as well, the file extension determines the default app that opens a document. So for example, double-clicking on an .afphoto file opens it in Affinity Photo & double-clicking on an .afdesign file opens it in Affinity Designer. If all the apps use the same extension, then the default app for all of them would have to be the same, which I doubt would be a desired behavior for the vast majority of users.

All affinity apps share file format and even edit ability when the hosting app doesn't natively support the feature. So if u open a Photo file with Live Filters in Designer, you can edit the live filter even thought Designer doesn't let u apply them. That's VERY Badass and the Devs Rock for such an ingenious feature!

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.

There is also a little brother to the Logitech Master - the Anywhere MX 2 - that is a very good alternative.  I managed to get one for £47 on Amazon.  It has all the same quality and similar features to the MX Master, and works just as well.  It's pitched as a mobile mouse, but is just as good for desktop.
 
I have no problems with the new Apple keyboard.  I got the new Magic Keyboard with my iMac, but I didn't have any choice else I'd have probably gone for the wired full keyboard.  I actually use cursor keys and the numeric pad a lot, and having it wired is not really an issue (plus you get two handy USB ports).

I'm going to suggest that the real problem is that the Magic Mouse is a totally flawed concept.  I got the Magic Mouse 2 with my new iMac, and it's been relegated to the drawer.  Trying to do gestures on the surface of an object that is too light to stay still is a joke. I ended up disabling everything but scroll and clicks - and scrolling was far from a nice experience.  In addition to that it is really temperamental with the bluetooth connection - often takes seconds to come to life after a rest.
 
So - my solution - I got a Logitech MX Master - it's bluetooth, rechargeable, has great scroll features, is ergonomically excellent, high precision, fully customisable, can be paired with three computers.... need I go on?  I do use it alongside a Magic Trackpad 2, for when I need to do any gestures.

If you measure the edges of the cube drawn in the Illustrator example (post transformation), you'll see that they are all the same length.  That, to me, is correct isometric ratio.
 
On the freehand one, the vertical is 0.86 (square root of 0.75 to be precise) the length of the two diagonals. That's why it looks squashed vertically.  It's not a pleasing cube if intended to be a parallel projection from the isometric view point.
 
Remember that isometric drawing was originally done on equilateral triangular grids.  To try this - use our Triangular grid (instead of Isometric), and you'll see exactly what I mean.
 

 
The grey cube, above, I drew the three faces using the pen tool and our Triangular grid.

As I said - I'll be adding tools to help convert or create shapes to isometric grid (or other grids).  I'll try and figure out a way of including projection proportions for the planes for when you convert a 'flat' shape to a plane.
 
I imagine a quick function to convert a 2D shape/object to one of the three planes would be handy, doing the transform for you in one go.  This would also enable you to transform embedded documents to plane.
 
If you enable "Create plane set" with an isometric grid, you'll be able to cycle through the planes with the ' key.

If you measure the edges of the cube drawn in the Illustrator example (post transformation), you'll see that they are all the same length.  That, to me, is correct isometric ratio.
 
On the freehand one, the vertical is 0.86 (square root of 0.75 to be precise) the length of the two diagonals. That's why it looks squashed vertically.  It's not a pleasing cube if intended to be a parallel projection from the isometric view point.
 
Remember that isometric drawing was originally done on equilateral triangular grids.  To try this - use our Triangular grid (instead of Isometric), and you'll see exactly what I mean.
 

 
The grey cube, above, I drew the three faces using the pen tool and our Triangular grid.

@Balling, You're technically correct, but it honestly feels like splitting hairs.
 
Every print shop I've worked with request a file at 300dpi... to achieve what they're asking for I create a document at 300ppi in PS/Ai/iD. The term dpi may be used incorrectly here, but in the 15 years I've been in design I've never once had a print shop ask for a file using the correct terminology. Correcting them would probably just make me look like a smug twat.
 
Designers don't have to worry about dpi unless they're the ones printing, but creating a document at 300 ppi or dpi (depending on your design software) is achieving what the print shop is asking for.
 
Kudos to you for learning and using the correct terminology (genuinely, not sarcastically), but changing dpi to ppi in Affinity's UI probably isn't going to make or break anything other than being technically correct.

Another tip - it's better to use "Groups" than "Layers" when creating symbols or assets as it enables you to select the entire symbol when clicking on spread. "Layers" click through, and so you will select one of the child layers, and not the whole layer.
 
In a UI prototyping situation, you'd want to be able to easily select the whole object and move/snap it.
 
"Layers" currently do not pass through for snapping bounding box calculations.  Anything in a "Layer" will currently not get added to snapping when using the "Immediate layers" option.  I'm in two minds as how this should work.  It's not really a bug, more a question of expectations.  I'm thinking that I might change it so they behave as "Groups" for the purpose of snapping.  Guess we'll have to see how this pans out when people use it.

@Herojas93
I emailed you back a modified document.
 
We have two kinds of layers - Logical and Physical.  Logical layers are shown as either "Layers" or "Groups" in the Layers panel.  Everything else is a physical layer (one that contributes something to the image).
 
As a general rule - Always try to make outer physical objects the parent of anything contained by them on the spread.  This enables a more efficient bounds calculation because it only needs to work with the outer shape.
 
Text objects especially should be children of an outer physical layer where possible.  So, for example, if text sits in front of a rectangle, and the rectangle won't clip the text geometry - make that text a child of the rectangle.

I've also spotted something else about this document which will hammer snapping performance.  A lot of the layers are made up of other nested "Layers" or "Groups".  There is nothing wrong with this in itself, but this pattern is unfortunately bad for snapping in this scenario.
 
If you have a top level Vector object, such as a rectangle, with child objects inside of that, the snapper can work out the bounding box of that layer by just calculating it for the rectangle (since its children will be clipped to it).  For "Layers" or "Groups" the snapper has to work out the bounding box by summing up the boxes for all the child objects.  This works recursively until it reaches a vector or pixel object for which it can calculate the real bounds.  Snapping in your document would be loads faster (with the options I mentioned before) if your top level layers were Vector objects (even if they are just used for clipping, with no fill or line colour).
 
This also applies if you have a surrounding rectangle with lots of objects as sibling objects in your document tree (such as your control panel images).  This would snap better if the details layers were children of the surrounding rectangle object.
 
For people making reusable symbols, this will be a good approach to follow.  We may release some "good practice tips" for forming Symbols and Assets when we have a few more snapping features in 1.6.
 
I also have some ideas for caching bounding boxes which will help performance, but a combination of this with well structured documents will give the best performance.