Junctions are like hard link and are not resolved by realpath (or readlink).

Did you ever read the provided test script?
Did you try to run it?
I can replace /J with /D, then you will not be able to run it without elevated privileges, but the result would not change.

And it is funny you mentioned readlink, because 'realpath.php':
<?php

$rootdir = substr($_SERVER['SystemRoot'], 0, 3);
$tmpdir = getenv('TEMP');
shell_exec("mklink /J \"{$rootdir}home\" \"{$rootdir}Users\"");
shell_exec("mklink /J \"{$tmpdir}\\test.dir\" \"{$rootdir}home\\Public\\Desktop\"");
$file = "{$tmpdir}\\test.dir\\desktop.ini";
$rfile = realpath($file);
printf("orig.file name: %s\n", $file);
printf("realpath(name): %s\n", $rfile);
printf("THE real name:  %s\n", realpath($rfile));
printf("readlink -fe:   %s\n", shell_exec("readlink -fe \"$file\""));
if($rfile != realpath($rfile))
  print "Fail as is.\n";

rmdir("{$rootdir}home");
rmdir("{$tmpdir}\\test.dir");

[C:\Programs\php-7.1.0b1]$ php.cmd -f realpath.php
orig.file name: C:\Users\ANRDAE~1\AppData\Local\Temp\test.dir\desktop.ini
realpath(name): C:\home\Public\Desktop\desktop.ini
THE real name:  C:\Users\Public\Desktop\desktop.ini
readlink -fe:   /c/Users/Public/Desktop/desktop.ini

Fail as is.

[C:\Programs\php-7.1.0b1]$

For your future genious resolutions, all NTFS symlinks are junctions, just with different attributes.

To begin with I have to ask you to change your tone if you like to have any kind of constructive answer.

By "Junctions are like hard link", I mean we handle them the same way.

About your "different attributes", everything is "just different attribute". It does not mean they behave or are the same.

This function solves symbolic link only, not junction, mount point or hard link.

See the code:
https://github.com/php/php-src/blob/ab39b094d2dcfb806c05913c53935a2540c887f3/Zend/zend_virtual_cwd.c#L970

and it is on purpose and by design. The same applies to other platforms with hard links for example.

About

"realpath() expands all symbolic links and resolves references to '/./', '/../' and extra '/' characters in the input path and returns the canonicalized absolute pathname."

It does not mean it does it for anything else but symbolic links.

We had a long discussion back then when I wrote symbolic support for Windows and the decision was to map cross platform behaviors and usage of junctions/mount points/etc by hosters and users.

If you need this kind of operations I remember an extension exposing all flags and attributes. That would give you access to the underlying APIs and do all kind of things. Many of them are not recommended as it brings another level of issues that may not supported by the engine, other extensions or external libraries (for some resulting paths). IfI leave alone the security aspects of it.

Yet again, did you try replacing "/J" with "/D" (directory symlink) in the supplied script?
Yes or no?

And just to add the last word:
The difference between hardlink and junction point is not how you treat them (which is subject to discussion), but the availability of information, which is an objective criteria.
Information about hardlinks and bind mounts is not available from a filesystem itself, you can only detect that they are not your regular files/directories, but can't find out, what they are in reality, without applying an external knowledge (consulting mounting tables/lookup full FS tree hashes/etc.).
Information about junctions/reparse points directly available from filesystem, and I see no reason to not use it, unless you want to make everybody's life harder for personal gains.