There are two separate considerations:

1. Did the line of sight pass through the block?
2. Did the line of sight actually intersect the block's contents (i.e. the volume enclosed by ``block.getHitbox()``) ?

Consider the player targeting a stone wall, in front of which there is a carpet block (0.0625 blocks high).  If the player is looking at the wall behind the carpet, then the targeted block will be the stone block.  ``getLineOfSight()`` will return a list of BlockTargetResult objects, the last element of which is the stone block - that element will have non-null ``getTargetFace()`` and ``getTargetLocation()`` returns.  The preceding element will be the carpet block - its ``getBlock()`` method returns the carpet block, but the ``getTargetFace()`` and ``getTargetLocation()`` methods will return null, indicating that the player's line of sight did not in fact intersect the carpet's hit box - it passed over it.

This is a fairly significant feature - the old API willl simply consider the carpet block to be targeted, even when the player's line of sight is nowhere near the actual carpet.  (But the ``useHitBoxes`` parameter for the various targeting methods is provided in case plugins want this behaviour).

Regarding perfect 45-degree angles: nothing's perfect when it comes to floating-point representations.  The calculations will always end up on one side of the block or other, and if the player's crosshairs are so finely positioned on a block boundary, they won't be able to tell the difference either.  I'm not sure what's significant about 45 degrees anyway - either the player's line of sight intersects a plane, or it doesn't, regardless of the angle.