This issue is more to document this behavior, I did check the GitHub issues but didn't see anything like this. Although I don't believe there is a reasonable solution that won't trigger some other obscure edge case.

The following Spring Boot 4.0.6 application throws a BeanCurrentlyInCreationException, I have not tested this against earlier versions based on Spring Framework 6.2, but it likely happens there as well.

@SpringBootApplication
public class BeanExampleApplication {

    public static void main(String[] args) {
        new SpringApplicationBuilder(BeanExampleApplication.class)
                .properties("spring.main.lazy-initialization=true")
                .run(args);
    }

    @Configuration // Non-static classes also triggers this. 
    public static class ExampleConfig {

        @Bean(bootstrap = Bean.Bootstrap.BACKGROUND)
        public Object backgroundBean() {
            return new Object();
        }

    }

}

In particular,

org.springframework.beans.factory.BeanCurrentlyInCreationException: Error creating bean with name 'beanExampleApplication.ExampleConfig': Bean marked for mainline initialization but requested in background thread - enforce early instantiation in mainline thread through depends-on 'beanExampleApplication.ExampleConfig' declaration for dependent background beans
	at org.springframework.beans.factory.support.DefaultListableBeanFactory.checkMergedBeanDefinition(DefaultListableBeanFactory.java:1051) ~[spring-beans-7.0.7.jar:7.0.7]
	at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:297) ~[spring-beans-7.0.7.jar:7.0.7]
	at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:196) ~[spring-beans-7.0.7.jar:7.0.7]
// the rest is omitted due to the reproducer

The "cleanest" solution I can think of is to have the LazyInitializationBeanFactoryPostProcessor check/declare a dependsOn relationship to the @Configuration class. Then the Configuration bean will be eagerly created before the Background bootstrap starts for the inner bean, removing the exception.

This doesn't prevent Application startup, but the exception can easily put developers on edge, and I haven't checked for other potential breaks.

Impact

This is only an issue when an Application leverages Lazy Init and a Library leverages @Bean(bootstrap = Bean.Bootstrap.BACKGROUND). Ideally the Application would be able to remove the "global" Lazy behavior and instead target specific beans that should be Lazy, but that isn't always possible during migration efforts. If the Application must use Lazy Init, then the Library has to declare an explicit dependsOn relationship to the @Configuration class. Depending on the Library, that might not be possible either.