Yeah, for similar reasons, the /proc/PID/wchan now shows just "0" (for other users' processes) on newer kernels, unless you run as root. Same with /proc/PID/stack, but it's implemented in a different way, I can open() that file successfully, but the read() syscall on the opened file descriptor returns EACCESS error...
$ ls -l /proc/$$/stack
-r-------- 1 tanel tanel 0 May 26 21:52 /proc/967141/stack
$
$ cat /proc/$$/stack
cat: /proc/967141/stack: Permission denied
$
$ sudo cat /proc/$$/stack
[<0>] do_wait+0x1c3/0x230
[<0>] kernel_wait4+0xaf/0x150
[<0>] __do_sys_wait4+0x85/0x90
[<0>] __x64_sys_wait4+0x1e/0x20
[<0>] do_syscall_64+0x49/0xc0
[<0>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
Edit: Adding one more comment - my impression has been that the "no userland-visible changes" promise applies to system calls - how procfs presents data as human-readable text in the /proc files has changed every now and then before (I recall the sar command showing wrong numbers after a kernel update, for example).
We've found userspace ABI does change in some surprising ways occasionally but mostly it doesn't matter to anybody.
e.g. we've seen the format of signal stack frames change in the past but nobody relies on that layout so it's OK.
/proc is another one along those lines - technically somebody could probably complain if it changes but if nobody shouts then it will just drift over time.
