Any update regarding this? I'm also facing same issue.
Right now I'm manually normalizing the pixel values using the solution mentioned here (https://stackoverflow.com/questions/29100722/equivalent-im2double-function-in-opencv-python)

Not sure if useful, but this seems to work fine on Windows.
The above code yields the following on Windows:
4.10.0
[190 145 161] [249 244 228]
[0 0 0] [1 1 1]
[0.76305221 0.58232932 0.64658635] [1. 0.97991968 0.91566265]

Still produces the wrong results on arm64 macOS when using float 32.

Reproducer:

#!/usr/bin/env python3
import cv2
import numpy as np
m = np.array([[ 1888, 1692, 369, 263, 199, 280, 326, 129, 143, 126, 233, 221, 130, 126, 150, 249, 575, 574, 63, 12]], dtype=np.float32)
print(cv2.__version__)
print(m.min(axis=(0, 1)), m.max(axis=(0, 1)))
mn = cv2.normalize(m, None, 0, 1, norm_type=cv2.NORM_MINMAX)
print(mn.min(axis=(0, 1)), mn.max(axis=(0, 1)))

Result is small negative which is wrong:

% ~/python311/bin/python3 testnorm.py
4.10.0
12.0 1888.0
-2.3283064e-10 1.0

Confirmed reproducer triggers a problem on Windows as well.

I was able to reproduce it in the C++ code

TEST(Normalize, regression_5877_inplace_change_type)
{
    std::vector<float> initial_values = { 1888, 1692, 369, 263, 280, 326, 129, 143, 126, 233, 221, 130, 126, 150, 249, 12 };
    Mat m(Size(16, 1), CV_32F, initial_values.data());
    normalize(m, m, 0, 1, NORM_MINMAX);
    float value = m.at<float>(0, 15);
    ASSERT_EQ(0, value);
}

test_arithm.cpp(2228): error: Expected equality of these values:
0
value
Which is: -2.32831e-10

I've traced the problem to the following line
opencv\modules\core\src\norm.cpp:1388. It's obviously a rounding error.

        if( rtype == CV_32F )
        {
            scale = (float)scale; //<---
            shift = (float)dmin - (float)(smin*scale);
        }

Changing the code to this:

        if( rtype == CV_32F )
        {
            scale = scale; //<--- Or you can just omit this line.
            shift = (float)dmin - (float)(smin*scale);
        }

Not rounding this yields
2.32831e-10 Which is > 0.

The line scale = (float)scale indeed doesn't look like making sense as smin is a double and in the next line the result is rounded anyway.

Added a small PR for this:
#26658 Feedback welcome.

I've created some code to find the smallest fit within the boundaries.

It appears tests are failing because it expects:

    TEST_CYCLE() cv::normalize(src, dst, 20., 100., NORM_MINMAX);
    SANITY_CHECK(dst, 1e-6, ERROR_RELATIVE);

expect_max evaluates to 100,
actual_max evaluates to 99.997268676757812, and
eps evaluates to 9.9999999999999991e-05.

If I'm not mistaking this means it allows to be outside of the interval. I hope an active contributor with more context can pitch in and decide what is most important:
a. the normalized results must fall within the interval
b. the normalized results may fall outside of the interval, in such a way that it is minimized.

That's too much change now and could cause the performance problems again the first try years ago caused which lead to being it reverted.

What about just clamping the result to the min value if it exceeds it? I.e. just adding something like this after shift = dmin - smin*scale;

if (shift < dmin)
shift = dmin

Ah I see the problem, the actual calculation is done in convertTo and not in the function where the current changes apply. Then the performance change risk is low.