When code has too much lines the buttom-right botton bar is not visible.
In case of managing several ml-controls this is quite annoying.

Don't seem to have that issue with 1080p almost-full-screen window, or when making it smaller either.

Max height for code part (iirc) is set as max_height = player.display_resolution.height - 350 and initial window Y offset to 150, so guess one way this can happen is if you have some kind of high-dpi display, where window header, button row and buttons at the bottom are scaled to be more than 200px tall or something like that.
Can you give a screenshot of when this happens?

Indeed my screen resolution is 3840x2160
Screenshot

If it helps I will send you the code also:

local function TransformPosition(position)
if var.Direction == 0 then
return position.x, position.y
end
if var.Direction == 1 then
return -position.y, position.x
end
if var.Direction == 2 then
return -position.x, -position.y
end
if var.Direction == 3 then
return position.y, -position.x
end
end

local function TransformSize(size)
if (var.Direction % 2) == 0 then
return size.x, size.y
end
return size.y, size.x
end

local function RunBluePrint(functionCode, position, size)
out["construction-robot"] = nil
out["deconstruction-planner"] = nil
out["signal-X"] = nil
out["signal-Y"] = nil
out["signal-W"] = nil
out["signal-H"] = nil
out["signal-R"] = nil

if not functionCode then
    return
end

if position then
    out["signal-X"], out["signal-Y"] = TransformPosition(position)
end
if size then
    out["signal-W"], out["signal-H"] = TransformSize(size)
end

if functionCode == -1 then
    out["deconstruction-planner"] = -1
else
    out["signal-R"] = var.Direction
    out["construction-robot"] = functionCode
end

end

local function CenterCorrection()
return math.floor(var.Direction / 2)
end

local function GetLongDelay()
local result = green["signal-D"]
if not result or result == 0 then
result = 300
end
return result
end

local function LabelIndex(instructions, target)
for index = 1, #instructions do
local instruction = instructions[index]
if instruction.Labels then
for labelIndex = 1, #instruction.Labels do
if instruction.Labels[labelIndex] == target then
return index
end
end
end
end
error("Unknown label " .. target)
end

local function Execute(instructions)
if not var.State then
var.State = 1
end

local instruction = instructions[var.State]
local nextLabel = instruction.Instruction()
if nextLabel then
    var.State = LabelIndex(instructions, nextLabel)
else
    var.State = var.State + 1
end
out["mlc"] = var.State
if var.State > #instructions then
    error("Unknown instruction " .. var.State)
end

end

local sizeToRemove = {x = 4, y = 31}

Execute {
{
Instruction = function()
var.Position = 0
var.Direction = (green["signal-R"] or 0) % 4
end
},
{
Labels = {"start"},
Instruction = function()
var.AdvanceExecuted = nil
RunBluePrint(1, {x = var.Position, y = 0})
end
},
{
Instruction = function()
RunBluePrint(nil)
end
},
{
Labels = {"mining"},
Instruction = function()
delay = GetLongDelay()
end
},
{
Instruction = function()
if green["signal-0"] == 0 then
return "mining"
end
end
},
{
Instruction = function()
RunBluePrint(-1, {x = var.Position + CenterCorrection() + sizeToRemove.x / 2, y = 0}, sizeToRemove)
end
},
{
Instruction = function()
RunBluePrint(nil)
var.Position = var.Position + 4
return "start"
end
}
}

Every long text, or even just empty lines should work the same, as they just stretch that text-box and scroll-pane it's in, until it gets to style.maximal_height and adds scrollbar for anything beyond that.

But, yeah, it looks like when UI scaling > 100% is enabled in options, factorio changes what it considers a "pixel" wrt UI sizes, but not for pixels in player.display_resolution values, so treating these as same unit for setting both width and height of windows is a mistake.
There should probably be a way to get that configuration parameter and add it as a factor to these formulas...

Should be fixed in 0.0.31.

Used display_scale factor to multiply window width/height and location values, and this seem to work at 2x scaling here.
That shifting definition for GUI units should take care of the rest in the same way as all base GUIs do (e.g. buttons with specified size=20 will be 2x size with 2x scaling), I think, so should be no need to change or re-calculate anything else there.