How do default values and union types work in React components?

I described my question with examples here:

https://codesandbox.io/s/gracious-diffie-hs57tc?file=/src/App.tsx

So basically I wonder why does setting the default value to a prop break a condition for types.
And the second question is why does passing children as a prop work with types fine but when calling children function in JSX it doesn't see correct types.

That's a tricky question, tried to find an answer in google, but didn't manage it

I played a little with your sandbox and figured out a few things.

.defaultProps

First of all I'd like to precise I just found it may be deprecated in the future, but it works...
For defining default values to props, you can use the defaultProps static field:

type Props = {
  flag: boolean;
};

const MyComp = ({ flag }: Props) => <p>{flag ? "Yes" : "No"}</p>;

MyComp.defaultProps = {
  flag: false
};

React.FC<>

I noticed that when we remove the flag in the first usage of the component, the same problem as the second appears. But I managed to fix it by adding the type React.FC<ComponentProps> to the component:

const Component: React.FC<ComponentProps> = ({ flag, children }: ComponentProps /* You can remove the parameter type from here if you want*/) => {
  // ...
};

Now, this code tell that isOpen does not exist, instead of both the "title and isOpen are any" thing:

<Component children={({ title, isOpen }) => <>{isOpen ? title : "Closed"}</>} />
//                             ^^^^^^
// Property 'isOpen' does not exist on type '{ title: string; }'.

The children type inference

About your last question, unfortunately, I didn't found any logical reason, and I think it looks like a React TypeScript bug.

I observed that if we remove the children value we get the following error:

<Component>{}</Component>
// Type 'never[]' provides no match for the signature '(props: { title: string; }): ReactNode'.

So we understand here that TypeScript is aware that the correct type is children, and tries to match it. But, for some reason, it is unable to infer the type of the parameter when we give the function. You can, as a workaround, strictly type it and it'll work (but I admit this is not a good solution)...

It seems that it cannot do the type inference with this syntax and in my opinion, you should open a bug report because this is not the correct behavior.