textscan() is a class in oct-stream.cc.  It implements its own read_double() function rather than relying on the read_value() function in lo-utils.cc.  It's just what I suspected.  The read_double() function has to parse each character, effectively replicating the work of the C++ library.

Localizing the problem.  dlmread calls read_value<double> which is located in liboctave/util/lo-utils.cc.  In turn, this eventually calls read_fp_value in the same file.  The eventual code is

        is >> val;

We are relying on the C++ stream libraries for reading "val" and those libraries understand 'e' for exponent but not 'd' for exponent.  There might be a way to hack the libraries in to recognizing 'd' for 'e' by making one's own locale.  This sounds difficult though.  Otherwise, we would need to write our own stream input routine that would read character-by-character and assemble a number.  That is precisely what the C++ library does and it sounds like a lot work to replicate that.

attempting to load a text file containing data using D as the exponential separator (apparently used in some systems to distinguish double and single precision data), load produces an error and dlmread reads the data ignoring the D and numbers the D.

e.g., a text file 'testdata.dat' containing:

1.00000 .509844D-02 .334798D-02 .100602D-03
2.00000 .511026D-02 .334856D-02 .101089D-03

(as well as a separate testdata2.dat where the D has been replaced with E)

in matlab:

>> format long

>> a = load('testdata.dat')
a =

   1.000000000000000   0.005098440000000   0.003347980000000   0.000100602000000
   2.000000000000000   0.005110260000000   0.003348560000000   0.000101089000000

>> b = dlmread('testdata.dat')

b =

   1.000000000000000   0.005098440000000   0.003347980000000   0.000100602000000
   2.000000000000000   0.005110260000000   0.003348560000000   0.000101089000000

>> c = textread('testdata.dat')

c =

   1.000000000000000   0.005098440000000   0.003347980000000   0.000100602000000
   2.000000000000000   0.005110260000000   0.003348560000000   0.000101089000000

>> fid = fopen('testdata.dat');d = textscan(fid, '%f %f %f %f')

d =

  1×4 cell array

    {2×1 double}    {2×1 double}    {2×1 double}    {2×1 double}

>> d{4}

ans =

   1.0e-03 *

   0.100602000000000
   0.101089000000000

>> e = importdata('testdata.dat', ' ')

e =

  2×1 cell array

    {'1.00000 .509844D-02 .334798D-02 .100602D-03'}
    {'2.00000 .511026D-02 .334856D-02 .101089D-03'}

>> e = importdata('testdata2.dat', ' ')

e =

   1.000000000000000   0.005098440000000   0.003347980000000   0.000100602000000
   2.000000000000000   0.005110260000000   0.003348560000000   0.000101089000000

>> f = readtable('testdata.dat')

f =

  2×4 table

    Var1       Var2          Var3          Var4
    ____    __________    __________    ___________

     1      0.00509844    0.00334798    0.000100602
     2      0.00511026    0.00334856    0.000101089

Not sure if I've missed any that should be tested.  So other than importdata, all matlab data reading functions appear able to properly interpret the D.

in Octave 6.2.1 (hg id: 6fc423987872):

>> format long

>> a = load('testdata.dat')
error: load: failed to read matrix from file 'testdata.dat'

>> b = dlmread('testdata.dat')
b =

   1.000000000000000   0.509844000000000   0.334798000000000   0.100602000000000
   2.000000000000000   0.511026000000000   0.334856000000000   0.101089000000000

>> c = textread('testdata.dat')
c =

     1
   NaN
   NaN
   NaN
     2
   NaN
   NaN
   NaN

>> fid = fopen('testdata.dat');d = textscan(fid, '%f %f %f %f')
d =
{
  [1,1] =

     1
     2

  [1,2] =

     5.098440000000001e-03
     5.110260000000000e-03

  [1,3] =

     3.347980000000000e-03
     3.348560000000001e-03

  [1,4] =

     1.006020000000000e-04
     1.010890000000000e-04

}

>>
>> d{4}
ans =

   1.006020000000000e-04
   1.010890000000000e-04

>>  e = importdata('testdata.dat', ' ')
e =

   1.000000000000000   0.509844000000000   0.334798000000000   0.100602000000000
   2.000000000000000   0.511026000000000   0.334856000000000   0.101089000000000

>> f = readtable('testdata.dat')
error: 'readtable' undefined near line 1, column 1

The 'readtable' function is not yet implemented in Octave.

So, it looks like in octave only textscan is able to interpret a D exponential separator.