A very simple example of a scenario where all the code is OK and you have compiled everything, but you still do not get the results you (rightfully) expect.
Well, I sure didn't expect them :-)

When you run the ted_p1188_b.test_type procedure below, you get the expected result; 1 for the ids and sysdate for sysdate.
begin ted_p1188_b.test_type; end; -- result: id_default = 1 id_constant = 1 id_function = 1 sys_date = 2025-02-27 07:30:58
If you then change the default values of both co_default and id_default in package ted_p1188_a from 1 to 2, recompile package ted_p1188_a, and run the ted_p1188_b.test_type procedure again, you get this: create or replace package ted_p1188_a is co_default constant integer := 2; function get_default return integer; type test_type is record ( id_default integer default 2 , id_constant integer default co_default , id_function integer default get_default , sys_date date default sysdate ) ; end ted_p1188_a; -- begin ted_p1188_b.test_type; end; -- result: id_default = 1 id_constant = 1 id_function = 2 sys_date = 2025-02-27 07:31:12
I expected both id_default and id_constant to return 2, but that's not the case.
And I also expected package ted_p1188_b to be invalid after recompiling package ted_p1188_a, but that's also not the case - and probably the cause of this behavior.
For some reason changing the default values in the specification of ted_p1188_a does not cause packages that use it, like ted_p1188_b, to become invalid. So those keep using the "old" version of the type specification.
Note that id_function works as expected because it uses a function (not very elegant, but it does work), and so does sysdate (which uses sysdate, which is also a function).

Just recompiling ted_p1188_b does not fix this; if you don't make an actual change, recompiling does nothing.
You need to make an actual change to ted_p1188_b (just adding a space somewhere is enough) and then recompile it for the package to "really" recompile. Only then do you get 2 as a result.

Not sure if this would happen with procedures, functions, triggers, types, etc. but it wouldn't surprise me.
To make things worse, running ted_p1188_b.test_type from the Apex Builder also shows 1 after the default has been changed to 2. And recompiling Apex is not an option of course.
So no idea what to do about this really, except never use defaults in types, or use them but never change them ever again, or use the clunky get_default function solution in ted_p1188_a. All not nice.

So that's something to keep in mind - the first time I encountered this behavior "in the wild" it took me an hour of debugging to pinpoint this. And then some time to rewrite it to something less elegant...