I played briefly with Marshall's adaptation of the script (though I upped to 60 instead of 5 loops, and before the exit I added a sleep(10);).

If I run cmd.exe, and from there run perl pm.pl, when I try to do any mouse, it is consumed by my cmd.exe > properties > options, so the script doesn't show any events. If I go to cmd.exe > properties > options, and turn off all the edit and text selection options, then run the script, it still grabs my mouse clicks -- and when I look, I see that it turned back on Quick Edit Mode and Insert Mode! If I do the sequence of run the script, then turn off all the edit options, if I click or wiggle, I do see a mouse event (#2):

C:\Users\peter.jones\Downloads\TempData\perl>perl pm.pl
Perl version v5.30.0
more text could go here

Your mouse has 5 buttons
calling input method!
An Event was detected! number= 6
event: 2
event: 42
event: 48
event: 1
event: 32
event: 0
[download]

Similarly, if I run from Explorer using my double-click association, so that it opens a new cmd.exe window (which doesn't inherit my default options with edit options enabled), I get events. (This was the reason I added the sleep(10): so that the created cmd.exe window wouldn't go away immediately after processing the mouse event(s).

update: As an aside, if I add the mode setting from vr's post (which I hadn't read yet when I created this post), modified to use Marshall's $IN console, then I find I don't need to futz with the cmd.exe properties manually. Thanks!

my $save = $IN-> Mode;
END { $IN-> Mode( $save )};
$IN-> Mode(( $save | 0x0010 ) & ~0x0040 ); # +MOUSE, -QUICK_EDIT
[download]

When looking at the adapted code, I have a nitpick and a query.

Nitpick: (this originated in fireblood's original): per Indirect Object Syntax, one should avoid the indirect-object style new Win32::Console(...) syntax, and instead use Win32::Console->new(...) syntax (or even the Win32::Console::->new(...) syntax; there are some circumstances where perl can interpret it ambiguously without both the :: and ->). It's not critical in this example, and I know that Win32::Console still recommends the old notation, but one can learn and use best practices even when the documentation/examples don't use it.

Query to Marshall: why are you throwing away the first @console_events ? You are actually getting two events, and only reporting the first. I can see this if I change the "calling input method!" print to $OUT->Write ("calling input method!" . @console_events . "(@console_events)\n");, at which point the above in-cmd.exe example becomes

C:\Users\peter.jones\Downloads\TempData\perl>perl pm.pl
Perl version v5.30.0
more text could go here

Your mouse has 5 buttons
calling input method!6(2 42 47 0 32 1)
An Event was detected! number= 6
event: 2
event: 42
event: 48
event: 1
event: 32
event: 0
[download]

For the if condition, did you really want to PeekInput of Win32::Console instead, or stick with GetEvents of Win32::Console as shown in the original, so that it polls whether there was an event, but doesn't remove the event from the queue? Or was there a specific reason for throwing away the first event?

Regarding the two mys, I am actually surprised there isn't a warning, because the my @console_events in the if condition is then masked by the my @console_events inside the block, but the use warnings isn't saying anything about it. (which it normally does, like in perl -le "use strict; use warnings; my $x; my $x" (warning: windows quote syntax, given the windows context of Win32::Console))

TL;DR

Back to the main point: if your cmd.exe window is not trapping the mouse inputs with its edit options, Win32::Console can see mouse events. But sometimes, when you think it won't trap, cmd.exe re-enables at least a couple of the traps, so you have to re-disable them after the program has started (edit: or by using the Mode command).