Here is a look at the internals with Devel::Peek:

$ perl -wMstrict -MDevel::Peek -le '$a=1; $b="$a"; Dump($a)'
SV = PVIV(0x5841e3fdfc40) at 0x5841e3fe36e0
  REFCNT = 1
  FLAGS = (IOK,POK,pIOK,pPOK)
  IV = 1
  PV = 0x5841e4024ad0 "1"\0
  CUR = 1
  LEN = 10
[download]

Here, you can see that the variable $a has both the string component PV = "1"\0, and it is marked as valid with POK, and an integer component IV = 1, also marked as valid with IOK. So they are both valid, and as I said, there is no reliable way to ask Perl for the difference. Modules like Data::Dumper have to guess what to output based on this internal information. (AFAICT from the source, the XS implementation of Data::Dumper simply prefers the integer version when that is valid. Other dumper modules handle such cases differently.)

What's going on here?

use warnings;
use strict;
use Data::Dumper;
use Devel::Peek;

my $n="1";
print Dumper $n;
Dump($n);
$n++;
print Dumper $n;
Dump($n);
$n--;
print Dumper $n;
Dump($n);

__END__

$VAR1 = '1';
SV = PV(0x53a29eb00fd0) at 0x53a29eb278b8
  REFCNT = 1
  FLAGS = (POK,IsCOW,pPOK)
  PV = 0x53a29ec907b0 "1"\0
  CUR = 1
  LEN = 10
  COW_REFCNT = 1
$VAR1 = '2';
SV = PV(0x53a29eb00fd0) at 0x53a29eb278b8
  REFCNT = 1
  FLAGS = (POK,pPOK)
  PV = 0x53a29ec3f310 "2"\0
  CUR = 1
  LEN = 10
$VAR1 = 1;
SV = PVIV(0x53a29eb23ac0) at 0x53a29eb278b8
  REFCNT = 1
  FLAGS = (IOK,pIOK)
  IV = 1
  PV = 0x53a29ec3f310 "2"\0
  CUR = 1
  LEN = 10
[download]

As you can see, what happens in this case internally is that the postincrement keeps only the string component, while the postdecrement converts it to an integer. If I had to guess why this is is the case, it might have to do with the "magic string increment" feature.

However, these are internal implementation details that one should not rely on!